TPC BENCHMARK ™ EStandard Specification
Version 1.14.0

April 2015

Transaction Processing Performance Council (TPC)
www.tpc.org
info@tpc.org© 2010 Transaction Processing Performance Council
All Rights Reserved

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 1 of 287

Legal Notice
The TPC reserves all right, title, and interest to this document and associated source code as provided
under U.S. and international laws, including without limitation all patent and trademark rights therein.
Permission to copy without fee all or part of this document is granted provided that the TPC copyrightnotice, the title of the publication, and its date appear, and notice is given that copying is by permissionof the Transaction Processing Performance Council. To copy otherwise requires specific permission.

No Warranty
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE INFORMATION CONTAINED HEREINIS PROVIDED “AS IS” AND WITH ALL FAULTS, AND THE AUTHORS AND DEVELOPERS OF THE WORKHEREBY DISCLAIM ALL OTHER WARRANTIES AND CONDITIONS, EITHER EXPRESS, IMPLIED OR
STATUTORY, INCLUDING, BUT NOT LIMITED TO, ANY (IF ANY) IMPLIED WARRANTIES, DUTIES OR
CONDITIONS OF MERCHANTABILITY, OF FITNESS FOR A PARTICULAR PURPOSE, OF ACCURACY ORCOMPLETENESS OF RESPONSES, OF RESULTS, OF WORKMANLIKE EFFORT, OF LACK OF VIRUSES, AND OFLACK OF NEGLIGENCE. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT,QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO
THE WORK.
IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THE WORK BE LIABLE TO ANY OTHER PARTY FORANY DAMAGES, INCLUDING BUT NOT LIMITED TO THE COST OF PROCURING SUBSTITUTE GOODS ORSERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT,INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE,
ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THE WORK, WHETHEROR NOT SUCH AUTHOR OR DEVELOPER HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCHDAMAGES.

Trademarks
TPC Benchmark, TPC-E, and tpsE are trademarks of the Transaction Processing Performance Council.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 2 of 287

Acknowledgments
The TPC acknowledges the work and contributions of the TPC-E subcommittee member companies:
AMD, Dell, Fujitsu-Siemens, HP, IBM, Ingres, Intel, Microsoft, NEC, Oracle, Sun, Sybase, and Unisys.
In addition, the TPC acknowledges the work of Trish Hogan as specification editor and the work andcontributions of InfoSizing.

TPC Membership(as of April 2015)
Full Members

Associate Members

Document Revision History
Date

VersionDescription

05-Dec-2006

1.0.0

Mail Ballot Draft

February
2007

1.0.0

Approved Standard Specification Officially approved.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 3 of 287

Editorial Change Number 1, Clause 1.2, fourth paragraph remove ‘s’ from “turns”.
(Motion 4)
Editorial Change Number 2, Remove the last two sentences from the Scaling Tables
section. (Motion 5)
27-Mar-2007

1.1.0

Editorial Change Number 3, change wording from “current revision of version 1 of the
TPC Pricing Specification” to “effective version of the TPC Pricing Specification”. (Motion
6)
Editorial Change Number 4, Update pseudo-code in Trade-Order frame 3 to include thehs_qty no rows returned situation. (Motion 7)
Editorial Change Number 5, Clarify Market-Watch pseudo-code. (Motion 11)03-Apr-2007

1.1.0

Editorial Change Number 6, editorial fixes for spaces and underscores and correctly
numbering things in Data-Maintenance, also Database Footprint corrections. (Motion 12)

10-Apr-2007

1.1.0

Editorial Change Number 7 clarifies the definition of “Application”. (Motion 14)

19-Apr-2007

1.1.0

Officially approved.

26-Apr-2007

1.2.0

Editorial Change Number 8 clarifies clause 2.2.3.4 which is about whether nulls areallowed in columns. (Motion 24)
Editorial Change Number 9 clarifies clause 3.2.1.1. A Frame may not use knowledge ofEGen’s data generation methods. (Motion 27)
Editorial Change Number 10, add “Profile” as a defined term and make changes to use
the new defined term. (Motion 28)
Editorial Change Number 11, in clause 3.3 change “profiles” to “characteristics” to avoid
ambiguity with the defined term. (Motion 29)
Editorial Change Number 12, in clause 1.1, deletes clause 3.2.1.3 text from the definitionof a Database Footprint. (Motion 30)
Editorial Change Number 13, clarify step 4 in clause 6.4.3.2. (Motion 31)
Editorial Change Number 14, in clause 2.2.5.5 removes the text in parenthesis from thedescription of the SE_AMT column. (Motion 34)

02-May-2007

1.2.0

Editorial Change Number 15, add text “during a Test Run” after “by the database” inclauses 2.2.3.1, 2.2.3.2, 2.2.3.3. (Motion 35)
Editorial Change Number 16, change the second sentence of clause 2.3.3.3. (Motion 36)
Editorial Change Number 17, in clause 10.2.2.15 correct the reference to clause 2.3.6 notclause 2.3.8. (Motion 37)
Editorial Change Number 18, add a comment to clause 10.2.2.20 saying no check isrequired for clause 2.4.2. (Motion 38)
Editorial Change Number 19, in clause 3.3.2.4 replace “customer” with “customer
account”. (Motion 39)
Editorial Change Number 20 clarifies the wording in clause 10.2.5.11. (Motion 41)
Editorial Change Number 21 adds the wording “unless otherwise directed by an auditor”
to clause 6.6.2.3. This wording allows sponsors to run database check code for the auditor
and allows the sponsor to run isolation tests. (Motion 47)

08-May-2007

1.2.0

Editorial Change Number 22, clarification of the wording used to describe some of the
Frames in Trade-Lookup and Trade-Update. (Motion 49)

23-May-2007

1.2.0

Editorial Change Number 23, Boolean and LIFO clarifications (Motion 55)
Editorial Change Number 24, roll_it_back changes (Motion 57)

30-May-2007

1.2.0

Editorial Change Number 25, typos and growth table fix (Motion 58)
Editorial Change Number 26, isolation test changes (Motion 59)
Editorial Change Number 27, clarification of the term “table” (Motion 60)

04-Jun-2007

1.2.0

Editorial Change Number 28, changes to clauses 4.4.1.1 and 10.2.4.11 wording (Motion
63)
Editorial Change Number 29, new clause 2.3.11 for User-Defined Objects (Motion 64)

06-Jun-2007

1.2.0

Editorial Change Number 30 clarifies when consistency tests need to be run and whattests should be run. (Motion 66)
Editorial Change Number 31, change title of clause 6.4 and 6.4.2, expand opening
paragraph of clause 6.4.2, remove constant TradeLookupFrame4MaxRows from the table

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 4 of 287

in clause 6.4.2 add a comment 2 to clause 3.2.1.1. (Motion 67)
Editorial Change Number 32, change the isolation tests in clause 7.4.2 to use transaction
parameter names instead of table column names. (Motion 68)
Editorial Change Number 33, remove hard-coded “CMPT” from frames 2 and 3 in TradeLookup and Trade-Update, make the necessary Database-Footprint changes. (Motion 69)
Editorial Change Number 34, Include the contents of the TRADE_TYPE and
STATUS_TYPE tables in the specification. (Motion 72)
Editorial Change Number 36, move clause 9.4.4.1 to clause 9.4.5.5. (Motion 74)
Editorial Change Number 37, accept the changes to the Numerical Quantities reporting
requirements as shown in DataMaintRespTimeTrish.doc (Motion 75)
Editorial Change Number 40, clarify the description of Market-Feed Frame 1 in clause
3.3.3.3 (Motion 79)

12-Jun-2007

1.2.0

Editorial Change Number 41, add select “first 3 rows” to the pseudo-code for TradeLookup and Trade-Update frames when we select from the TRADE_HISTORY table.
(Motion 80)
Editorial Change Number 42, change the Market-Feed Frame 1 pseudo-code to use
distinct variable names (Motion 82)
Editorial Change Number 44, add a comment to clause 6.6.5.3 to clarify the checkpoint
requirements (Motion 85).
Editorial Change Number 45, apply several editorial changes from the auditors (Motion
86)
Editorial Change Number 46, change table to TPC-E table in clause 2.3.4 (Motion 87)
Editorial Change Number 47, change table to TPC-E table in clause 2.3.5 (Motion 88)
Editorial Change Number 48, move clause 6.4.2 limit constants table to clause 3.2.1.1(Motion 89)
Updated TPC Membership table with BEA and EnterpriseDB
Editorial Change Number 35, add clause 6.2.5 Driver Reporting Requirements. Moveclause 9.3.4.1 to clause 9.3.6.1. Change the reference in the new clause 9.3.6.1 to reference
the new clause 6.2.5 instead of clause 4.1.3. (Motion 73)

15-Jun-2007

1.3.0

Editorial Change Number 38, add definition for “Database Metadata” to clause 1.1(Motion 77).
Editorial Change Number 39, clean up the reference to “Metadata” and use the newly
defined term “Database Metadata” (Motion 78).
Editorial Change Number 43, change Market-Watch Frame 1 pseudo-code. Remove thelast “else” “rollback transaction”. Move the “commit transaction” outside of the “if(status != bad_input_data)” check so that the commit is unconditional. (Motion 84)
Change Number 49, clarify clause 6.6.2.1 so that measured runs do not have to be on a
freshly restored database (Motion 99).
Another Change Number 49, add wording to clause 6.7.4.2 to define the level of precision
required for the input standard deviation (Motion 101).
Change Number 51 - fix various typos (Motion 105).
Change Number 52 and part of Change Number 50, add wording to appendix A.6.4 to
document the #define flags to use to change the date/time format (Motion 107 andMotion 103).
Change Number 53 - change Trade-Result to return the load unit number (Motion 108).

28-Aug-2007

1.3.0

Change Number 54 – clarify clause 10.2.8.2 and clause 10.2.8.3 so that the auditor just has
to check that the files that are expected are in the Supporting Files but does not have toverify every file is correct (Motion 109).
Change Number 55 – change bullet 3 of Clause 7.5.6.7 to say “one or more” instead of“one” (Motion 110).
Change Number 56 – in clause 10.2.2.14 change “table” to “TPC-E table” to match clause
2.3.5 (Motion 111).
Change Number 57 – change comment 2 of Clause 7.5.5.2 (Motion 112).
Change Number 58 – replace clause 10.2.5.14 and use Sustainable performance rather
than Steady state (Motion 114).
Change Number 59 – delete the last sentence of Clause 10.2.5.2. Change the reference inClause 10.2.5.2 to Clause 6.6.2.2. Change the reference in Clause 10.2.5.3 to Clause 6.6.1.1(Motion 115).

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 5 of 287

Change Number 60 – change the definition of Dispatch Time (Motion 118).
Change Number 61 – clarify Clause 6.6.2.3 wording, renumber Clause 10 and clarify what
was clause 10.2.5.13 (Motion 120)
Change Number 62 – remove the tables listed in parenthesis from Clause 6.6.6.2 (Motion
121).
Change Number 63 – change comment 2 of Clause 8.2.1 (Motion 122).
Change Number 64 – replace clause 7.5.5.4 with new Redundancy Level wording (Motion
124).
Change Number 65 – delete Clause 9.3.7.3 and modify Clause 9.3.7.2 (Motion 125).
Change Number 66 – correct the reference in Clause 10.2.5.4 to point to Clause 6.3(Motion 126).
Change Number 67 – change the wording of Clause 10.2.5.19 (Motion 127).
Change Number 68 – delete Clause 10.2.4.8 (Motion 129).
Change Number 69 – change the definition of the Boolean data-type (Motion 130).
Change Number 70 – in Clause 7.5 replace the word “deemed” with the word “defined”(Motion 131).
Change Number 71 – fix the style of Clause 7.4.2.4 step 7 (Motion 134).
Change Number 72 – part 1 of clarifying field/attribute/column (Motion 135).
31-Aug-2007

1.3.0

Change Number 73 – change diagrams to make them more readable on a black and white
print out (Motion 136).
Change Number 74 – clarify CE Partitioning (Motion 137).

05-Sep-2007

1.3.0

17-Sep-2007

1.4.0

Change Number 75 – clarify isolation test descriptions (Motion 140).
Change Number 76 – clarify old clause 10.2.5.15 (now clause 10.6.14) (motion 141).
Changed member’s list to include Exasol.
Change Number 77 – part 2 of clarifying field/attribute/column (Motion 148).
Change Number 78 – drop third bullet in clause 6.6.4.2 (Motion 160)

25-Sep-2007

1.4.0

Change Number 79 – clarify Referential Integrity requirements (Motion 166).

02-Oct-2007

1.4.0

Change Number 80 – clarify the term connector in clause 4.4.1.3 (Motion 170).

17-Oct-2007

1.4.0

Change Number 81 – in clause 8.2, clarify what storage may be used to meet the 60-Day
space requirements (Motion 173).

07-Nov-2007

1.4.0

Editorial cleanup of headings to be consistent. Added the word “Transaction” to theheadings in Clauses 3.3.2.2 and 3.3.3.2.

14-Nov-2007

1.4.0

Change Number 82 – clarify 5% or 8-hour growth rate wording by adding a comment to
the Fixed Space definition in clause 6.6.6.2 (Motion 181).

27-Nov-2007

1.4.0

Change Number 83 – change appendix A.6.4 to include #define for Booleans (Motion
184).
Change Number 84 – Editorial change to 10.2.14 (Motion 186).
Change Number 85 – Clarify third sentence of Clause 2.6.1.1 (Motion 188).

03-Dec-2007

1.4.0

Change Number 86 – Clarify the definition of Growing Space (Motion 189).
Change Number 87 – Add Clause 9.3.5.5 to add reporting requirements for the buildingof EGen Objects (Motion 190).

13-Dec-2007

1.5.0

Changed member’s list to include ParAccel and to change NCR-Teradata to just Teradata.
Change Number 88 – changes to Business Recovery Time (Motion 191).
Fixed cross references in Application Recovery Time and Business Recovery Timedefinitions.

13-Feb-2008

1.5.0

Change Number 89 – Add a new clause 5.7.3 to specify what the DBMS should do if
EGenLoader generates an empty string (Motion 206).
Change Number 90 – Clarify step 8 in clause 7.5.6.8 (Motion 212).

27-Feb-2008

1.5.0

Change Number 91 – add comment 3 to clause 3.1.2.3 saying that select for update isallowed when the Database Footprint says a Reference is required (Motion 215)
Change Number 92 – Replace Clause 3.2.1.6 with a clearer description of what it means to
be functionally equivalent to the pseudo-code (Motion 216)

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 6 of 287

Change Number 93 – clarify Clause 6.3.3 – Data-Maintenance must run every 58 to 63
seconds (Motion 217)
Removed BEA and EnterpriseDB from membership list.
14-Mar-2008

1.5.1

Change Number 94 – change “account” to “acct_id” in the pseudo-code for Trade-Order
Frame 3 (Motion 228)

18-Mar-2008

1.5.1

Change Number 95 – re-order clause 10 (Motion 236)

15-Apr-2008

1.5.1

Change Number 97 – In clause 2.3.9 change the cross reference from 6.6.6.1 to 6.6.6.2(Motion 240).
Change Number 96 – Add status checking to EGenTxnHarness pseudo-code (Motion
237).
Change Number 98 – Clarify clause 8.2.1 (Motion 241)
Change Number 99 – Change clause 1.1 60-Day Period definition by replacing “indices”
with “User-Defined Objects” (Motion 242)

19-May-2008

1.6.0

Change Number 100 – Change clause 2.3.9 comment by replacing “associated objects”
with “associated User-Defined Objects” (Motion 243)
Change Number 101 – Change clause 8.2.1 replace “indices” with “User-Defined Objects”(Motion 244)
Change Number 102 – Change clause 9.3.2.1 replace “indices” with “User-Defined
Objects” (Motion 245)
Change Number 103 – Change clause 2.2.4.4 replace “indices” with “references” and“index” with “reference” (Motion 246)
Change Number 104 – Add sentence to clause 4.4.1.6 (Motion 253)
Added Fusion-IO, Greenplum, Kickfire and Vertica to TPC members table.

12-Jun-2008

1.6.0

Fixed some errors in Change Number 96 – Add status checking to EGenTxnHarness
pseudo-code (Motion 237).
Change Number 106 - In Clause 6.5.2.1 added parenthesis around sTn – eTn-1 (Motion266).

17-Jun-2008

31-Jul-2008

13-Aug-2008

1.6.0

Change Number 105 – change to Change Number 96 which added status checking, backout the “if (list_len == 0) then status = +111” from Broker-Volume (Motion 265).

1.6.0

Change Number 107 – Change C_F_NAME and AP_F_NAME from CHAR(30) to
CHAR(20). Change C_L_NAME and AP_L_NAME form CHAR(30) to CHAR(25).
Change CO_CEO from CHAR(100) to CHAR(46). Change T_EXEC_NAME from
CHAR(64) to CHAR(46). Change B_NAME from CHAR(100) to CHAR(49).

1.6.0

Editorial changes T_EXEC_NAME from CHAR(46) to CHAR(49) because Trade-Update
Frame 1 can add a middle initial to it. Made the corresponding change to ex_namechar(64) to char(49) in Trade-Update Frame 1 pseudo-code. Updated diagram A.b insection A.13 moved the yellow and purple striped line that goes from CMEESUTInterface
to cyan DoTxn to go to purple DoTxn instead.
Change Number 108 – move “min_day_len” before “max_day_len” in table 3.2.1.2(Motion 272).
Change Number 109 – Combine the first two lines of clause 3.2.1.8 (Motion 273)
Change Number 110 – Clarify the last two lines of clause 3.2.1.8 (Motion 274)

11-Sep-2008

1.6.0

Change Number 113 – In Market-Feed Frame 1 Parameters change the description of“status” to use the word “Frame” instead of the word “Transaction” (Motion 278)
Change Number 116 – In Trade-Lookup Frame 4 pseudo-code change status = -641 tostatus = +641 (Motion 282)
Change Number 117 – Add “, DM” to the first line of clause 10.6.2.1 (Motion 283)
Change Number 118 – In clause 3.3.11 change 10c to 10C (Motion 284)
Change Number 119 – Change “LOB” to “BLOB” and add the definition BLOB_REF(Motion 287)
Change Number 111 – Add table to clause 3.2.1.8 listing EGen warnings and where they
happen in the code (Motion 275)

19-Nov-2008

1.7.0

Change Number 112 – Change comment in Customer-Position Frame 2 pseudo-code in
Clause 3.3.2.4 to read “Should return 10 to 30 rows” (Motion 277)
Change Number 114 – Remove the max_send_len constant from clause 3.2.1.2 and the

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 7 of 287

Market-Feed pseudo code (Motion 279)
Change Number 115 – Change the Market-Feed pseudo-code in Clause 3.3.3.3 to reflect
logic changes (Motion 280)
Change Number 120 – Add “and outputs” to 1st and 3rd sentences of clause 9.4.2.1(Motion 291)
Change Number 121 – Update the table in clause 9.3.9.1 to move the entries listed in
Clause 4 to Clause 5 to be consistent with clause 9.4.5.5. Retain the entry for Clause 4
adding a notation that no files are required (Motion 302)
Change Number 122 – Modify the 3-second interval to a 30-second interval in Clause
6.4.2.2 (Motions 312 and 316)
Change Number 124 – Remove “status=+412 from Market-Watch pseudo-code in Clause
3.3.4.3
Change Number 125 – Updated table in Clause 3.2.1.8 to include additional warnings
Change Number 126 – Modified Clause 5.3.1 to reflect TPC policies change
Change Number 127 – Modified Clause 8.2.1 Comment 1 to include “solid-state storage”
to the list of on-line storage examples
11-Jun-2009

1.8.0

Change Number 129 – Modified Clause 7.5 to rework durability definitions andprocedures
Change Number 130 – Corrected typos in Clause 7.5.2, 7.5.3.2, and 7.5.4. Removed
redundant wording in Clause 7.5.5 and 7.5.6.1. Modified Clause 6.7.2 wording to
expand description of the graph requirements. Modified Clause 7.5.5.6. Modified
Clause 7.5.6.7 for consistency of wording. Modified Clause 7.5.7 to clarify steps requiredfor durability testing. Modified Clause 7.5.8.3 to add a line to the graph at 95% of thereported throughput. Modified Clause 7.6.7.2 for wording consistency.
Change Number 131 – Modified Clause 3.2.1.8 and 3.3.7.5 to remove the +734 statuscheck.

17-Sep-2009

1.9.0

Change Number 135 – Added bullet to Clause 8.1 to address heterogeneous storage
devices
Change Number 136 – Modified Clause 8.1 to clarify the usage of Free Space
Change Number 137 – Added “Free Space and/or” to the second bullet of Clause 8.1.
Change Number 138 – Changed “8 hours of execution” to “Business Day” in the second
bullet of Clause 8.1.
Change Number 139 – Changed both occurrences of “Digits” with “decimal places” inClause 6.3.2.
Change Number 140 – Corrected various typos and editorial issues.
Change Number 141 – Corrected various typos and editorial issues.
Change Number 143 – Inserted a new Clause 6.6.6.2 for initial database size.
Change Number 144 – Moved the computation of 60-day space (Clause 8.2.2) to Clause
6.6.6.6.
Change Number 145 – Removed the term “Network” from Clause 8.1.

11-Feb-2010

1.10.0Change Number 146 – Added definition of Measured Configuration.
Change Number 147 – Moved Clause 8.2.1 to a new Clause 6.6.7.
Change Number 148 – Added wording to Clauses 0.1.1, 6.7.3, 9.1, and 10.1.3 to support
TPC-Energy.
Change Number 150 – Modified TPC-Energy wording in Clause 0.1.1.
Change Number 151 – Removed comment 1 and 2 from 6.6.6.6.
Change Number 152 – Removed the second sentence of Clause 6.6.6.6; DeletedComment 1 from Clause 6.6.7; Renamed “Comment 2” to “Comment” in Clause 6.6.7;
Removed the parenthetical statement in Clause 8.1; Used the defined term “On-Line” inClauses 6.6.7 and 8.1; Added the definition of On-Line as Clause 8.2.1; Modified Clause
8.2.2.
Change Number 153 – Removed bullets 2 and 3 from Clause 8.1; added new bullet 2 toClause 8.1.
Revised TPC membership list

22-Apr-2010

1.11.0Change Number 123 – – Moved status checks from Market-Feed from pseudo-code to
the harness; updated the status check for Last_Trade updates, added a frame output for
the number of rows updated.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 8 of 287

Change Number 128 - Moved status checks for +641, -711, -721, -811, and -911 from thepseudo-code to the harness and added frame/transaction output for the number of rows
found.
Change Number 132 – Changed the cust_assets variable name to acct_assets to moreaccurately reflect what is being computed in Clause 3.3.7.5.
Change Number 142 – Reconciled harness pseudo-code with actual harness code
implementation.
Change Number 149 – Removed the status output parameter from each frame.
Change Number 159 – Replaced TAX_RATE with TAXRATE in Clause 3.3.8.2; Removed
the empty bullet in Clause 8.1; Replaced “need be” with “may be” in Clause 8.2.4.

25-Jun-2010

1.12.0Change Number 160 – Modified Clause 7.6 to rework Data Accessibility definitions andprocedures (Motion 451)
Revised TPC membership list
Change Number 161 – Add Reported Metrics section to Clause 7.6. Move the text from
7.5.8.2 to this new section and strike Clause 7.5.8.2
Change Number 162 - Updated Clauses 3.3.7.5 and 3.3.10.3 to refine status checks andensure that EGen and the specification are consistent
Change Number 163 – Added wording for numeric precision, rounding, and reporting
requirements to Clauses 6.6.8.4, 6.7.1.1, 6.7.1.2, and 6.7.1.3
Change Number 164 – Durability and Data Accessibility editorial changes
Change Number 165 – Modified the definition of Vulnerable Storage Component andthe associated example
Change Number 166 – Added Clause 7.6.3.6; modified Clause 9.3.7.2; added 10.7.5.4 todefine requirements for combinations of durable media technologies
Change Number 167 – Removed last sentence from Clause 6.6.8.4; Update Clause 9.3.6.2
to read “The Reported Throughput must be reported in the Report (see Clause 6.7.1.2).”(Motion 481)
Change Number 168 – Remove the entry for MeasuredThroughput in Appendix C.2.4.
(Motion 482)
Change Number 169 – Removed Clause 6.7.1.3; update Clause 6.7.1.1 to remove thereference to Clause 6.7.1.3; Updated the definition of Reported Throughput to remove
the reference to Clause 6.7.1.3; Changed the reference in 10.6.6.2 to be 6.7.1.2 rather than
6.7.1. (Motion 483)

24-Feb-2014

1.13.0Change Number 170 – Replaced “one minute average tpsE” in Clause 6.7.2 with “TradeResults per second averaged over one minute”; Removed “one-minute averagethroughput in tpsE (computed as the” and the trailing parenthess from the 3rd sentencein Clause 6.7.2; Changed the caption of Figure 6.f to read “Example of Test Run Graph”;
Changed the y-axis label of Figure 6.f to read “Trade-Result Transactions per second”(Motion 484)
Change Number 171 – Replaced “actual tpsE” with “Measured Throughput” in Clause
6.7.4.2. (Motion 485)
Change Number 172 – Modified second paragraph of Clause 6.5.2.3: added “in order tomeet the requirements of Clause 6.7.1” to the first sentence; removed the second
sentence. (Motion 487)
Change Number 173 – Replaced all occurrences of “tpsE” with “completed TradeResults per second” in Clause 7.5.6.7. (Motion 488)
Change Number 174 – Replaced “one-minute average tpsE” with “Trade-Results per
second averaged over one-minute” in Clauses 7.5.8.2 and 7.6.4.2. Removed “the tpsE”
from the second bullet in Clauses 7.5.8.2 and 7.6.4.2. (Motion 489)
Change Number 175 – Replaced “reported tpsE” with “Reported Throughput” in Clause
6.6.7. (Motion 490)
Change Number 176 – Modified status checks in Clause 3.3.6.6; Modified status checks
in Clause 3.3.10.4 and 3.3.10.5; Updated warnings table in Clause 3.2.1.8. (Motion 495)
Change Number 177 – Modified Clauses 7.6.3.6 and 7.6.4.1 to clarify tested components
for the Data Accessibility tests. (Motion 497)
Change Number 178 – Corrected subscript notation in Market Feed pseudo-code in
Clause 3.3.3. (Motion 521)
Change Number 179 – Removed non-existant EGen structure references from Clauses

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 9 of 287

3.3.2.1, 3.3.7.1, 3.3.8.1, 3.3.11.1, and 3.3.12.1. (Motion 524)
Change Number 180 – Modified Clause 4.4.1.6 to change clause reference. (Motion 525)
Change Number 181 – Modified description for cust_id in parameters table of Clause
3.3.7.5. (Motion 528)
Change Number 182 – Added Clause 7.5.5.2 for prohibiting restore/roll forward
recovery and updated subsequent clause numbers. (Motion 529)
Change Number 183 – Modified formatting in Clause 7.6.2 to properly show definedterms. (Motion 530)
Change Number 184 – Removed the last sentence of Clause 7.5.3.1. (Motion 541)
Change Number 185 – Updated Appendix A Clauses A.1, A.2.1, A.3.1, A.5.1, A.13 1a,and A.13 2a to reflect the code changes in EGen 1.13.
Change Number 186 – Updated Appendix A Clause 14 for CInputFiles ->DataFileManager changes.
Change Number 187 – Updated TPC Membership chart
Change Number 188 – Added comment to Clause 7.5.5.3 to address reactive actions
within the SUT resulting from Instantaneous Failures.
Change Number 189 – Editorial change to Clause 3.1.2.3 to fix formatting problems withbullets
23-Apr-2015

1.14.0Change Number 190 – Editorial change to Database Footprint table in Clauses 3.1.2.3,
3.3.4.2, 3.3.5.2, 3.3.7.2, 3.3.10.2, and 3.3.12.2 to make “Transaction Control” row
formatting consistent
Change Number 191 – Editorial change to Clause 3.3.11 to correct missing text when
linking to the data_maintenance bookmark
Change Number 192 – Modify TPC Membership to reflect new members and logos

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 10 of 287

Typographic Conventions
The following typographic conventions are used in this specification:
Convention

Description

Bold

Bold type is used to highlight terms that are defined in this document

Italics

Italics type is used to highlight a variable that indicates some quantity whose value can be
assigned in one place and referenced in many other places.

UPPERCASE

Uppercase letters indicate database schema object names such as table and column names. In
addition, most acronyms are in uppercase.

Diagram Color-Coding Conventions
Concept
CustomerLight Green with down diagonal hashing

BrokerPale Blue with up diagonal hashingMarketRose with horizontal hashing

Implementation
TPC Provided CodeTurquoise Italics

Sponsor Provided CodeLavender Underline

Commercially Available Product

Light Yellow

Table of Contents
Clause 0 -- Preamble ............................................................................................................................................................... 18
0.1 Introduction ................................................................................................................................................................. 18
0.1.1
Goal of the TPC-E Benchmark ..................................................................................................................... 18
0.1.2
Restrictions and Limitations.......................................................................................................................... 19
0.2

General Implementation Guidelines ............................................................................................................................ 19

0.3

General Measurement Guidelines ............................................................................................................................... 20

Clause 1 -- Benchmark Overview .......................................................................................................................................... 21
1.1

Definitions ................................................................................................................................................................... 21

1.2

Business and Application Environment ....................................................................................................................... 43

1.3 Transaction Summary .................................................................................................................................................. 44
1.3.1
Broker-Volume ............................................................................................................................................. 44
1.3.2
Customer-Position ......................................................................................................................................... 44
1.3.3
Market-Feed .................................................................................................................................................. 44
1.3.4
Market-Watch ............................................................................................................................................... 45
1.3.5
Security-Detail .............................................................................................................................................. 45
1.3.6
Trade-Lookup ................................................................................................................................................ 45
1.3.7
Trade-Order ................................................................................................................................................... 45
1.3.8
Trade-Result .................................................................................................................................................. 45
1.3.9
Trade-Status .................................................................................................................................................. 45
1.3.10Trade-Update ................................................................................................................................................ 45
1.3.11
Data-Maintenance ......................................................................................................................................... 46
1.3.12
Trade-Cleanup ............................................................................................................................................... 46
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 11 of 287

1.4 Model Description ....................................................................................................................................................... 46
1.4.1
Entity Relationships ...................................................................................................................................... 46
1.4.2
Differences between Customer Tiers ............................................................................................................ 46
1.4.3
Customer Partitioning ................................................................................................................................... 46
1.4.4
Trade Types................................................................................................................................................... 47
1.4.5
Effects of Trading on Holdings ..................................................................................................................... 47
Clause 2 -- Database Design, Scaling & Population ............................................................................................................. 48
2.1 Introduction ................................................................................................................................................................. 48
2.1.1
Definitions ..................................................................................................................................................... 48
2.2 TPC-E Database Schema and Table Definitions ......................................................................................................... 48
2.2.1
Data Type Definitions ................................................................................................................................... 48
2.2.2
Meta-type Definitions ................................................................................................................................... 49
2.2.3
General Schema Items ................................................................................................................................... 50
2.2.4
Customer Tables............................................................................................................................................ 51
2.2.5
Broker Tables ................................................................................................................................................ 55
2.2.6
Market Tables ............................................................................................................................................... 59
2.2.7
Dimension Tables.......................................................................................................................................... 63
2.3 Implementation Rules .................................................................................................................................................. 65
2.3.3
Table Partitioning .......................................................................................................................................... 65
2.3.11
User-Defined Objects .................................................................................................................................... 66
2.4

Integrity Rules ............................................................................................................................................................. 67

2.5

Data Access Transparency Requirements ................................................................................................................... 67

2.6 TPC-E Database Size and Table Cardinality .............................................................................................................. 68
2.6.1
Initial Database Size Requirements ............................................................................................................... 68
2.6.2
Test Run Database Size Requirements .......................................................................................................... 71
Clause 3 -- Transactions ......................................................................................................................................................... 73
3.1 Introduction ................................................................................................................................................................. 73
3.1.1
Definitions ..................................................................................................................................................... 73
3.1.2
Database Footprint Definition ....................................................................................................................... 73
3.2 Transaction Implementation Rules .............................................................................................................................. 76
3.2.1
Frame Implementation .................................................................................................................................. 76
3.2.2
Customer Partitioning and Generating Transaction Inputs ........................................................................... 79
3.3 The Transactions ......................................................................................................................................................... 79
3.3.1
The Broker-Volume Transaction................................................................................................................... 80
3.3.2
The Customer-Position Transaction .............................................................................................................. 83
3.3.3
The Market-Feed Transaction ....................................................................................................................... 90
3.3.4
The Market-Watch Transaction .................................................................................................................... 95
3.3.5
The Security-Detail Transaction ................................................................................................................. 100
3.3.6
The Trade-Lookup Transaction ................................................................................................................... 108
3.3.7
The Trade-Order Transaction ...................................................................................................................... 122
3.3.8
The Trade-Result Transaction ..................................................................................................................... 140
3.3.9
The Trade-Status Transaction ..................................................................................................................... 160
3.3.10The Trade-Update Transaction.................................................................................................................... 163
3.3.11
The Data-Maintenance Transaction ............................................................................................................ 176
3.3.12The Trade-Cleanup Transaction .................................................................................................................. 190
Clause 4 -- Description of SUT, Driver, and Network ....................................................................................................... 195
4.1 Overview .................................................................................................................................................................... 195
4.1.1
Description of the Real-World OLTP Environment.................................................................................... 195
4.1.2
Functional Component Abstraction of the Real-World OLTP Environment .............................................. 195
4.1.3
Distillation of Functional Components into the TPC-E Environment ......................................................... 196
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 12 of 287

4.2

Driver & System Under Test (SUT) Definitions ........................................................................................................ 200

4.3

Example Test Configuration Implementations .......................................................................................................... 201

4.4 Further Requirements for SUT and Driver Implementations .................................................................................... 203
4.4.1
Restrictions on the Driver ........................................................................................................................... 203
4.4.2
Disclosure of Network Configuration ......................................................................................................... 204
4.4.3
SUT Implementation Limits on Operator Intervention ............................................................................... 204
4.4.4
Synchronization of Time ............................................................................................................................. 204
Clause 5 -- EGen ................................................................................................................................................................... 205
5.1

Overview .................................................................................................................................................................... 205

5.2

EGen Terms ............................................................................................................................................................... 205

5.3 Compliant EGen Versions ......................................................................................................................................... 206
5.3.5
Using EGen within a Compliant Driver ...................................................................................................... 206
5.3.6
Addressing Errors in EGen ......................................................................................................................... 206
5.3.7
Process for Reporting Issues with EGen ..................................................................................................... 207
5.3.8
Submitting EGen Enhancement Suggestions .............................................................................................. 207
5.4

EGenProjectFiles ...................................................................................................................................................... 208

5.5

EGenInputFiles ......................................................................................................................................................... 208

5.6

EGenSourceFiles ....................................................................................................................................................... 208

5.7

EGenLoader .............................................................................................................................................................. 208

5.8 EGenDriver ............................................................................................................................................................... 208
5.8.5
EGenDriverCE ............................................................................................................................................ 209
5.8.6
EGenDriverMEE ......................................................................................................................................... 209
5.8.7
EGenDriverDM ........................................................................................................................................... 209
5.9

EGenTxnHarness....................................................................................................................................................... 209

5.10

EGenValidate........................................................................................................................................................ 209

Clause 6 -- Execution Rules & Metrics ............................................................................................................................... 210
6.1 Introduction ............................................................................................................................................................... 210
6.1.1
Definition of Terms ..................................................................................................................................... 210
6.2 Driver Implementation Architectures ........................................................................................................................ 210
6.2.1
The Simple CE ............................................................................................................................................ 210
6.2.2
The Replicated CE ...................................................................................................................................... 211
6.2.3
The Asynchronous CE ................................................................................................................................ 212
6.2.4
Combinations .............................................................................................................................................. 214
6.2.5
Driver Reporting Requirements .................................................................................................................. 214
6.3 Transaction Mix ........................................................................................................................................................ 214
6.3.1
Mix Requirements ....................................................................................................................................... 215
6.3.2
Required Precision for Mix Percentage Reporting ...................................................................................... 215
6.3.3
Data-Maintenance ....................................................................................................................................... 215
6.3.4
Trade-Cleanup ............................................................................................................................................. 215
6.4 Transaction Parameters ............................................................................................................................................ 216
6.4.1
Input Value Mix Requirements ................................................................................................................... 216
6.4.2
Customer Partitioning ................................................................................................................................. 217
6.5 Response Time and Pacing Delays ............................................................................................................................ 218
6.5.1
Response Time ............................................................................................................................................ 218
6.5.2
Dispatch Time and Pacing Delay ................................................................................................................ 221
6.6 Test Run ..................................................................................................................................................................... 221
6.6.1
Definition of Terms ..................................................................................................................................... 221
6.6.2
Database Content ........................................................................................................................................ 222
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 13 of 287

6.6.3
6.6.4
6.6.5
6.6.6
6.6.7
6.6.8

Sustainable Performance ............................................................................................................................. 222
Steady State ................................................................................................................................................. 223
Measurement Interval .................................................................................................................................. 223
Database Growth ......................................................................................................................................... 223
Continuous Operation Requirement ............................................................................................................ 224
Performance & Database Size ..................................................................................................................... 225

6.7 Required Reporting ................................................................................................................................................... 225
6.7.1
Reported Throughput .................................................................................................................................. 225
6.7.2
Test Run Graph ........................................................................................................................................... 226
6.7.3
Primary Metrics ........................................................................................................................................... 226
6.7.4
EGenValidate Results ................................................................................................................................. 226
Clause 7 -- Transaction and System Properties (ACID) .................................................................................................... 228
7.1

ACID Properties ........................................................................................................................................................ 228

7.2 Atomicity Requirements ............................................................................................................................................. 228
7.2.1
Atomicity Property Definition .................................................................................................................... 228
7.2.2
Atomicity Tests ........................................................................................................................................... 229
7.3 Consistency Requirements ......................................................................................................................................... 229
7.3.1
Consistency Property Definition ................................................................................................................. 229
7.3.2
Consistency Conditions ............................................................................................................................... 229
7.3.3
Consistency Tests ........................................................................................................................................ 229
7.4 Isolation Requirements .............................................................................................................................................. 230
7.4.1
Isolation Property Definition ....................................................................................................................... 230
7.4.2
Isolation Tests ............................................................................................................................................. 231
7.5 Durability Requirements ........................................................................................................................................... 235
7.5.1
Definition of Commit .................................................................................................................................. 235
7.5.2
Definition of Vulnerable Storage Component ............................................................................................. 235
7.5.3
Definition of Single Point(s) of Failure ....................................................................................................... 235
7.5.4
Definition of Durable / Durability ............................................................................................................... 236
7.5.5
Durability Testing Rules and Guidelines .................................................................................................... 236
7.5.6
Definition of Recovery Terms ..................................................................................................................... 239
7.5.7
Durability Test Procedure for Single Points of Failures .............................................................................. 240
7.5.8
Required Reporting for Durability .............................................................................................................. 241
7.6 Data Accessibility Requirements ............................................................................................................................... 242
7.6.1
Definition of Terms ..................................................................................................................................... 242
7.6.2
Data Accessibility Throughput Requirements............................................................................................. 242
7.6.3
Failure of Durable Media ............................................................................................................................ 243
7.6.4
Required Reporting for Data Accessibility ................................................................................................. 245
Clause 8 -- Pricing ................................................................................................................................................................. 246
8.1

Priced Configuration ................................................................................................................................................. 246

8.2 On-line Storage Requirement .................................................................................................................................... 246
8.2.5
Archive Operation Requirement ................................................................................................................. 247
8.2.6
Back-up Storage Requirements ................................................................................................................... 247
8.3 TPC-E Specific Pricing Requirements....................................................................................................................... 247
8.3.1
Additional Operational Components ........................................................................................................... 247
8.3.2
Additional Software .................................................................................................................................... 247
8.4

Component Substitution............................................................................................................................................. 247

8.5

Required Reporting ................................................................................................................................................... 248

Clause 9 -- Full Disclosure Report ....................................................................................................................................... 250
9.1

Full Disclosure Report Requirements ....................................................................................................................... 250
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 14 of 287

9.1.1

General Items .............................................................................................................................................. 250

9.2 Executive Summary Statement ................................................................................................................................... 250
9.2.1
First Page of the Executive Summary Statement ........................................................................................ 251
9.2.2
Additional Pages of Executive Summary Statement ................................................................................... 251
9.2.3
ES.xml Requirements .................................................................................................................................. 252
9.3 Report Disclosure Requirements ............................................................................................................................... 252
9.3.1
Report Introduction ..................................................................................................................................... 252
9.3.2
Clause 2 Database Design, Scaling & Population Related Items ................................................................ 254
9.3.3
Clause 3 Transaction Related Items ............................................................................................................ 256
9.3.4
Clause 4 SUT, Driver, and Network Related Items .................................................................................... 256
9.3.5
Clause 5 EGen Related Items ...................................................................................................................... 256
9.3.6
Clause 6 Performance Metrics and Response Time Related Items ............................................................. 256
9.3.7
Clause 7 Transaction and System Properties Related Items ........................................................................ 257
9.3.8
Clause 8 Pricing Related Items ................................................................................................................... 257
9.3.9
Supporting Files Index Table ...................................................................................................................... 257
9.4 Supporting Files ........................................................................................................................................................ 258
9.4.1
SupportingFiles/Introduction Directory ...................................................................................................... 258
9.4.2
SupportingFiles/Clause2 Directory ............................................................................................................. 259
9.4.3
SupportingFiles/Clause3 Directory ............................................................................................................. 259
9.4.4
SupportingFiles/Clause4 Directory ............................................................................................................. 259
9.4.5
SupportingFiles/Clause5 Directory ............................................................................................................. 259
9.4.6
SupportingFiles/Clause6 Directory ............................................................................................................. 259
9.4.7
SupportingFiles/Clause7 Directory ............................................................................................................. 259
9.4.8
SupportingFiles/Clause8 Directory ............................................................................................................. 259
Clause 10 -- Independent Audit ........................................................................................................................................... 260
10.1

General Rules ....................................................................................................................................................... 260

10.2
Auditing the Database .......................................................................................................................................... 261
10.2.1
Schema Related Items ................................................................................................................................. 261
10.2.2
Population Related Items ............................................................................................................................ 262
10.3

Auditing the Transactions ..................................................................................................................................... 262

10.4

Auditing the SUT, Driver and Networks ............................................................................................................... 263

10.5

Auditing EGen ...................................................................................................................................................... 264

10.6
Auditing the Execution Rules and Metrics ............................................................................................................ 265
10.6.1Pre-run Configuration Items ........................................................................................................................ 265
10.6.2
Runtime Configuration Items ...................................................................................................................... 265
10.6.3
Runtime Data Generation Items .................................................................................................................. 265
10.6.4
Response Time Items .................................................................................................................................. 266
10.6.5
C_ID Partitioning Items .............................................................................................................................. 266
10.6.6
Throughput Items ........................................................................................................................................ 266
10.6.7
Data-Maintenance Items ............................................................................................................................. 266
10.6.8
Steady State Items ....................................................................................................................................... 266
10.6.9EGenValidate Items .................................................................................................................................... 266
10.6.10
Space Calculation Items .............................................................................................................................. 267
10.7
Auditing the ACID Tests ....................................................................................................................................... 267
10.7.2
Atomicity Items ........................................................................................................................................... 267
10.7.3
Consistency Items ....................................................................................................................................... 267
10.7.4Isolation Items ............................................................................................................................................. 267
10.7.5
Data Accessibility Items.............................................................................................................................. 267
10.7.6
Business Recovery Items ............................................................................................................................ 267
10.8

Auditing the Pricing .............................................................................................................................................. 268

10.9

Auditing the FDR .................................................................................................................................................. 268
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 15 of 287

Appendix A. EGen User’s Guide .......................................................................................................................................... 270
A.1

Overview ............................................................................................................................................................... 270

A.2

EGen Directory..................................................................................................................................................... 270

A.3

EGenProjectFiles ................................................................................................................................................. 271

A.4

EGenInputFiles ..................................................................................................................................................... 271

A.5

EGenSourceFiles .................................................................................................................................................. 271

A.6

EGenLoader.......................................................................................................................................................... 271

A.7

EGenDriver .......................................................................................................................................................... 273

A.8

EGenLogger.......................................................................................................................................................... 274

A.9

Implementing a CE using EGenDriverCE ............................................................................................................ 274

A.10

Implementing a MEE using EGenDriverMEE ...................................................................................................... 274

A.11

Implementing a Data-Maintenance Generator using EGenDriverDM ................................................................ 275

A.12

EGenTxnHarness .................................................................................................................................................. 275

A.13

Functional Implementation ................................................................................................................................... 276

A.14

TPC Defined Interfaces ........................................................................................................................................ 278

Appendix B. Executive Summary Statement ...................................................................................................................... 280
B.1

Sample Layouts ..................................................................................................................................................... 280

B.2

Sample Executive Summary Statement ................................................................................................................. 281

Appendix C. TPC-E XML Schema Guide ........................................................................................................................... 285
C.1

Overview ............................................................................................................................................................... 285

C.2

Schema Structure .................................................................................................................................................. 285

Table of Figures
Figure 1.a - Business Model Transaction Flow .................................................................................................................... 43
Figure 1.b - Application Components ................................................................................................................................... 44
Figure 3.a - Frames Interfacing with the Harness and the Database ................................................................................... 73
Figure 4.a - Diagram of the Real-World OLTP Environment ............................................................................................ 195
Figure 4.b - Abstraction of the Functional Components in an OLTP Environment ........................................................... 196
Figure 4.c - Functional Components of the Test Configuration ......................................................................................... 197
Figure 4.d - Defined Components of the Test Configuration .............................................................................................. 200
Figure 4.e - Sample Component of Physical Test Configuration ........................................................................................ 201
Figure 4.f - Separate Driver with Combined Tier A and Tier B ......................................................................................... 202
Figure 4.g - Driver and Tier A Combined, Separate Tier B ............................................................................................... 202
Figure 4.h - Combined Driver, Tier A and Tier B .............................................................................................................. 203
Figure 6.a - The Simple CE ................................................................................................................................................ 211
Figure 6.b - The Replicated CE .......................................................................................................................................... 212
Figure 6.c – Asynchronous Transaction Generator ............................................................................................................ 213
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 16 of 287

Figure 6.d – Non-Blocking Driver Threads of Execution ................................................................................................... 214
Figure 6.e - Measuring Response Time .............................................................................................................................. 220
Figure 6.f - Example of the Test Run Graph ....................................................................................................................... 226
Figure 9.a - Example of Measured Benchmark Configuration ........................................................................................... 253
Figure A.a - Hierarchy of EGen Directory ......................................................................................................................... 270
Figure A.b - High Level Overview of a Sample Implementation ........................................................................................ 276

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 17 of 287

CLAUSE 0 -- PREAMBLE
0.1

Introduction
TPC Benchmark™ E (TPC-E) is an On-Line Transaction Processing (OLTP) workload. It is a mixture of
read-only and update intensive transactions that simulate the activities found in complex OLTP
application environments. The database schema, data population, transactions, and implementation
rules have been designed to be broadly representative of modern OLTP systems. The benchmark
exercises a breadth of system components associated with such environments, which are characterizedby:

The simultaneous execution of multiple transaction types that span a breadth of complexity;Moderate system and application execution time;

A balanced mixture of disk input/output and processor usage;

Transaction integrity (ACID properties);A mixture of uniform and non-uniform data access through primary and secondary keys;



Databases consisting of many tables with a wide variety of sizes, attributes, and relationships withrealistic content;Contention on data access and update.

The TPC-E operations are modeled as follows:

0.1.1



The database is continuously available 24 hours a day, 7 days a week, for data processing frommultiple Sessions and data modifications against all tables, except possibly during infrequent (e.g.,
once a month) maintenance Sessions.



Due to the worldwide nature of the application modeled by the TPC-E benchmark, any of thetransactions may be executed against the database at anytime, especially in relation to each other.

Goal of the TPC-E Benchmark
The TPC-E benchmark simulates the OLTP workload of a brokerage firm. The focus of the benchmark
is the central database that executes transactions related to the firm’s customer accounts. In keepingwith the goal of measuring the performance characteristics of the database system, the benchmark does
not attempt to measure the complex flow of data between multiple application systems that would exist
in a real environment.
The mixture and variety of transactions being executed on the benchmark system is designed tocapture the characteristic components of a complex system. Different transaction types are defined tosimulate the interactions of the firm with its customers as well as its business partners. Different
transaction types have varying run-time requirements.
The benchmark defines:

Two types of transactions to simulate Consumer-to-Business as well as Business-to-Businessactivities

Several transactions for each transaction type

Different execution profiles for each transaction type

A specific run-time mix for all defined transactions

For example, the database will simultaneously execute transactions generated by systems that interact
with customers along with transactions that are generated by systems that interact with financial
markets as well as administrative systems.
The benchmark system will interact with a set of Driver systems that simulate the various sources oftransactions without requiring the benchmark to implement the complex environment.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 18 of 287

The Performance Metric reported by TPC-E is a "business throughput” measure of the number ofcompleted Trade-Result transactions processed per second (see Clause 6.7.1). Multiple Transactions
are used to simulate the business activity of processing a trade, and each Transaction is subject to a
Response Time constraint. The Performance Metric for the benchmark is expressed in transactionsper-second-E (tpsE). To be compliant with the TPC-E standard, all references to tpsE Results must
include the tpsE rate, the associated price-per-tpsE, and the Availability Date of the Priced
Configuration (See Clause 6.7.3 for more detail).
To be compliant with the optional TPC-Energy standard, the additional primary metric, expressed as
watts-per-tpsE, must be reported. The requirments of the TPC-Energy Specification can be found at
www.tpc.org.
Although this specification defines the implementation in terms of a relational data model, the database
may be implemented using any commercially available Database Management System (DBMS),
Database Server, file system, or other data repository that provides a functionally equivalent
implementation. The terms "table", "row", and "column" are used in this document only as examples oflogical data structures.
TPC-E uses terminology and metrics that are similar to other benchmarks, originated by the TPC andothers. Such similarity in terminology does not imply that TPC-E Results are comparable to otherbenchmarks. The only benchmark Results comparable to TPC-E are other TPC-E Results that conformto a comparable version of the TPC-E specification.
0.1.2

Restrictions and Limitations
Despite the fact that this benchmark offers a rich environment that represents many OLTP applications,this benchmark does not reflect the entire range of OLTP requirements. In addition, the extent to whicha customer can achieve the Results reported by a vendor is highly dependent on how closely TPC-E
approximates the customer application. The relative performance of systems derived from thisbenchmark does not necessarily hold for other workloads or environments. Extrapolations to any otherenvironment are not recommended.
Benchmark Results are highly dependent upon workload, specific application requirements, andsystems design and implementation. Relative system performance will vary because of these and otherfactors. Therefore, TPC-E should not be used as a substitute for specific customer application
benchmarking when critical capacity planning and/or product evaluation decisions are contemplated.
Benchmark Sponsors are permitted various possible implementation designs, insofar as they adhere to
the model described and pictorially illustrated in this specification. A Full Disclosure Report (FDR) of
the implementation details, as specified in Clause 9.1, must be made available along with the reported
Results.
Comment: While separated from the main text for readability, comments are a part of the standard andmust be enforced.

0.2

General Implementation Guidelines
The purpose of TPC benchmarks is to provide relevant, objective performance data to industry users.
To achieve that purpose, TPC benchmark specifications require that benchmark tests be implemented
with systems, products, technologies and pricing that:Are generally available to users.



Are relevant to the market segment that the individual TPC benchmark models or represents (e.g.,
TPC-E models and represents high-volume, complex OLTP database environments).



A significant number of users in the market segment the benchmark models or represents would
plausibly implement.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 19 of 287

The use of new systems, products, technologies (hardware or software) and pricing is encouraged solong as they meet the requirements above. Specifically prohibited are benchmark systems, products,
technologies, pricing (hereafter referred to as "implementations") whose primary purpose isperformance optimization of TPC benchmark Results without any corresponding applicability to realworld applications and environments. In other words all "benchmark specials” implementations that
improve benchmark Results but not real-world performance or pricing, are prohibited.
The following characteristics should be used as a guide to judge whether a particular implementation isa benchmark special. It is not required that each point below be met, but that the cumulative weight ofthe evidence be considered to identify an unacceptable implementation. Absolute certainty or certainty
beyond a reasonable doubt is not required to make a judgment on this complex issue. The questionthat must be answered is this: based on the available evidence, does the clear preponderance (thegreater share or weight) of evidence indicate that this implementation is a benchmark special?
The following characteristics should be used to judge whether a particular implementation is abenchmark special:Is the implementation generally available, documented, and supported?



Does the implementation have significant restrictions on its use or applicability that limits its use
beyond TPC benchmarks?

Is the implementation or part of the implementation poorly integrated into the larger product?

Does the implementation take special advantage of the limited nature of TPC benchmarks (e.g.,transaction Profile, Transaction Mix, transaction concurrency and/or contention, transaction isolation)
in a manner that would not be generally applicable to the environment the benchmark represents?

0.3

Is the use of the implementation discouraged by the vendor? (This includes failing to promote theimplementation in a manner similar to other products and technologies.)



Does the implementation require uncommon sophistication on the part of the end-user,
programmer, or system administrator?

Is the pricing unusual or non-customary for the vendor, or unusual or non-customary to normal
business practices? See the effective version of the TPC Pricing Specification for additional
information.

Is the implementation being used (including beta) or purchased by end-users in the market area thebenchmark represents? How many? Multiple sites? If the implementation is not currently being
used by end-users, is there any evidence to indicate that it will be used by a significant number ofusers?

General Measurement Guidelines
TPC benchmark Results are expected to be accurate representations of system performance. Therefore,
there are certain guidelines, which are expected to be followed when measuring those Results. The
approach or methodology is explicitly outlined in or described in the specification.


The approach is an accepted engineering practice or standard.



The approach does not enhance the Results.

Equipment used in measuring Results is calibrated according to established quality standards.



Fidelity and candor is maintained in reporting any anomalies in the Results, even if not specified in
the benchmark requirements.

The use of new methodologies and approaches is encouraged so long as they meet the requirements
above.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 20 of 287

CLAUSE 1 -- BENCHMARK OVERVIEW
1.1

Definitions
NUMBERS _____________________
60-Day Period
Storage must be priced for sufficient space to store and maintain the data and User-Defined Objects
generated during a period of 60 Business Days at the Reported Throughput called the 60-Day Period.

60-Day SpaceThe 60-Day Space must be computed as:
60-Day Space = Initial Database Size + (60 * Data Growth)

A ___________________________
ACID
ACID – the transactional properties of Atomicity, Consistency, Isolation and Durability.

Add
The word “Add” indicates that a number of rows are added to the TPC-E table specified by the
Database Footprint. TPC-E Table row(s) can only be added in a Frame where the word “Add” isspecified.

Application
The term Application or Application Program refers to code that is not part of the commerciallyavailable components of the SUT, but used specifically to implement the Transactions (see Clause 3.3)of this benchmark. For example, stored procedures, triggers, and referential integrity constraints are
considered part of the Application Program when used to implement any portion of the Transactions,but are not considered part of the Application Program when solely used to enforce integrity rules (seeClause 2.4) or transparency requirements (see Clause 2.5) independently of any Transaction.

Application Recovery
Application Recovery: the process of recovering the business application after a Single Point ofFailure and reaching a point where the business meets certain operational criteria.

Application Recovery Time
Application Recovery Time: The elapsed time between the start of Application Recovery and the endof Application Recovery (see Clause 7.5.6.5).

Arbitrary Transaction

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 21 of 287

An Arbitrary Transaction is a Database Transaction that executes arbitrary operations against the
database at a minimum isolation level of L0 (see Clause 7.4.1.3).

Attestation Letter
Attestation Letter: The Auditor’s opinion regarding the compliance of a Result must be consigned in
an Attestation Letter delivered directly to the Sponsor.

AuditorSee TPC-Certified Auditor.

Availability Date
The date when all products necessary to achieve the stated performance will be available (stated as asingle date on the Executive Summary Statement). This is known as the Availability Date.

B ___________________________BALANCE_T
BALANCE_T is defined as SENUM(12,2) and is used for holding aggregate account and transaction
related values such as account balances, total commissions, etc.

BLOB(n)BLOB(n) is a data type capable of holding a variable length binary object of n bytes.

BLOB_REF
BLOB_REF is a data type capable of referencing a BLOB(n) object that is stored outside the table on the
SUT.

BOOLEANBOOLEAN is a data type capable of holding at least two distinct values that represent FALSE and
TRUE.

Brokerage Initiated
Brokerage Initiated: These Transactions simulate broker interactions with the system and are initiatedby the Customer Emulator component of the benchmark Driver.

Broker Tables
Broker Tables: This set includes 9 tables that contain information about the brokerage firm and broker
related data.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 22 of 287

Business Day
Business Day: a period of eight hours of transaction processing activity.

Business Recovery
Business Recovery: the process of recovering from a Single Point of Failure and reaching a point
where the business meets certain operational criteria.

Business Recovery TimeBusiness Recovery Time: the elapsed period of time between start of Business Recovery and end of
Business Recovery (see Clause 7.5.6.9).

C ___________________________
Catastrophic
Catastrophic: a type of failure where processing is interrupted without any foreknowledge given to the SUT.
Subsequent to this interruption, only in the failed database instance are all contexts for all active
applications lost and all memory cleared.

CE
See Customer Emulator.

CHAR(n)CHAR(n) means a character string that can hold up to n single-byte characters. Strings may be paddedwith spaces to the maximum length. CHAR(n) must be implemented using a Native Data Type.

Commit / Committed
Commit: a control operation that:

Is initiated by a unit of work (a Transaction)

Is implemented by the DBMS

Signifies that the unit of work has completed successfully and all tentatively modified data areto persist (until modified by some other operation or unit of work)

Upon successful completion of this control operation both the Transaction and the data are said to be
Committed.

Configured Customers
Configured Customers means the number of customers (with corresponding rows in the associated
TPC-E tables) configured at database generation.

Customer Emulator
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 23 of 287

One key piece of a compliant TPC-E Driver is the Customer Emulator (CE). The CE is responsible for
emulating customers, requesting a service of the brokerage house, providing the necessary input for therequested service, etc. Therefore, the CE is responsible for the following.


Deciding which Customer Initiated or Brokerage Initiated Transaction to perform next (BrokerVolume, Customer-Position, Market-Watch, Security-Detail, Trade-Lookup, Trade-Order, TradeUpdate and Trade-Status).



Generating compliant data to be used as inputs for the selected Transaction.

Sending the Transactionrequest and associated input data to the SUT.



Receiving the Transactionresponse and associated output data from the SUT.



Measuring the Transaction's Response Time.

Comment: The CE may optionally perform additional operations as well, such as statistical accounting,data logging, etc.

Customer InitiatedCustomer Initiated: These Transactions simulate customer interactions with the system and are
initiated by the Customer Emulator component of the benchmark Driver.

Customer Tables
Customer Tables: This set includes 9 tables that contain information about the customers of thebrokerage firm.
D ___________________________
Data Accessibility
Data Accessibility: The ability to maintain database operations with full data access after thepermanent irrecoverable failure of any single Durable Medium containing database tables, recovery
log data, or Database Metadata.
Data Accessibility Throughput Requirements
Data Accessibility Throughput Requirements:
Accessibility tests (see Clause 7.6.2).

Conditions the SUT must satisfy for all Data

Data-Maintenance Generator
Another key piece of a compliant TPC-E Driver is the single instance of the Data-Maintenance
Generator (DM). The DM is responsible for:


Generating compliant data to be used as inputs for the Data-Maintenance Transaction

Sending the Transaction’s request and associated input data to the SUT

Receiving the Transaction’s response and associated output data from the SUT and measuring theTransaction’s Response Time.

Comment: The DM may optionally perform additional operations as well, such as statistical accounting,data logging, etc. The DM may optionally be used to initiate a single Trade-Cleanup Transaction
before the start of a Test Run.

Database Footprint
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 24 of 287

The Database Footprint of a Transaction is the set of required database interactions to be executed bythat Transaction.

Database Interface
Database Interface – Commercially available product used by the Frame Implementation tocommunicate with the Database Server. It is possible that the Database Interface may communicate
with the Database Server over a Network, but this is not a requirement.

Database Logic
Database Logic – Sponsor written Frame implementation logic (e.g. stored SQL procedure).

Database Management System
A Database Management System (DBMS) is a collection of programs that enable you to store, modify,
and extract information from a database. There are many different types of DBMSs, ranging from small
systems that run on personal computers to huge systems that run on mainframes. From a technicalstandpoint, DBMSs can differ widely. The terms relational, network, flat, and hierarchical all refer tothe way a DBMS organizes information internally. The internal organization can affect how quickly
and flexibly you can extract information. Requests for information from a database are made in theform of a query, which is a stylized question. The set of rules for constructing queries is known as aquery language. The information from a database can be presented in a variety of formats. Most
DBMSs include a report writer program that enables you to output data in the form of a report.

Database Metadata
Database Metadata: information managed by the DBMS and stored in the database to define, manage
and use the database objects, e.g. tables, views, synonyms, value ranges, indexes, users, etc.

Database Recovery
Database Recovery: the process of recovering the database from a Single Point of Failure system
failure.

Database Recovery Time
Database Recovery Time: the duration from the start of Database Recovery to the point when databasefiles complete recovery.

Database Server
Database Server – Commercially available product(s). Sponsor provided logic may run in the context
of the Database Server (e.g. a stored SQL procedure). An example of a Database Server is:commercially available DBMS running on a

commercially available Operating System running on a

commercially available hardware system utilizingcommercially available storage
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 25 of 287

Database Session
To work with a database instance, to make queries or to manage the database instance, you have toopen a Database Session. This can happen as follows: The user logs on to the database with a username and password, thus opening a Database Session. Later, the Database Session is terminatedexplicitly by the user or closed implicitly when the timeout value is exceeded. A database tool
implicitly opens a Database Session and then closes it again.

Database Transaction
A Database Transaction is an ACID unit of work.

Data Growth
Data Growth: the space needed in the DBMS data files to accommodate the increase in the Growing
Tables resulting from executing the Transaction Mix at the Reported Throughput during the period of
required Sustainable performance.
Data Growth = Data-Space-per-Trade-Result * tpsE * Business Day duration in seconds

DATE
DATE represents the data type of date with a granularity of a day and must be able to support therange of January 1, 1800 to December 31, 2199, inclusive. DATE must be implemented using a Native
Data Type.
Comment: A time component is not required but may be implemented.

DATETIMEDATETIME represents the data type for a date value that includes a time component. The datecomponent must meet all requirements of the DATE data type. The time component must be capable ofrepresenting the range of time values from 00:00:00 to 23:59:59. Fractional seconds may be
implemented, but are not required. DATETIME must be implemented using a Native Data Type.

DBMS
See Database Management System

Digit
Digit means decimal digit.

Dimension Tables
Dimension Tables: This set includes 4 dimension tables that contain common information such asaddresses and zip codes.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 26 of 287

Dispatch Time
Each EGenDriverCE thread of execution calling the EGenDriver Connector interface creates asequence of Transactions, defined chronologically as { T1, T2, … Tn }. Within each sequence, theDispatch Time of Transaction n is defined as follows:

for the Non-Blocking Driver Thread architecture (see 6.2.3.2)
For n=1: DTn = 0

For n>1: DTn = (sTn – sTn-1)

for all other architectures in Clause 6.2


For n=1: DTn = 0

For n>1: DTn = sTn – eTn-1

Where sTn and eTn are defined in Clause 6.5.1.1

DM
See Data-Maintenance Generator.

DriverTo measure the performance of the OLTP system, a simple Driver generates Transactions and their
inputs, submits them to the System Under Test, and measures the rate of completed Transactions
being returned. To simplify the benchmark and focus on the core transactional performance, allapplication functions related to user interface and display functions have been excluded from thebenchmark. The System Under Test is focused on portraying the components found on the server sideof a transaction monitor or application server.

Durability
See Durable.

Durability Throughput Requirements
Durability Throughput Requirements: conditions the SUT must satisfy for all Durability tests (seeClause 7.5.5.1).

Durable / Durability
Durable / Durability: In general, state that persists across failures is said to be Durable and an
implementation that ensures state persists across failures is said to provide Durability. In the context
of the benchmark, Durability is more tightly defined as the SUT’s ability to ensure all Committed data
persist across any Single Point of Failure.

Durable Medium
Durable Medium: a data storage medium that is inherently non-volatile such as a magnetic disk ortape. Durable Media is the plural of Durable Medium.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 27 of 287

E ___________________________
EGen
EGen is a TPC provided software environment that must be used in a Test Sponsor's implementationof the TPC-E benchmark. The software environment is logically divided into three packages:
EGenProjectFiles, EGenInputFiles, and EGenSourceFiles.
The software packages provide
functionality to use: EGenLoader to generate the data used to populate the database, EGenDriver togenerate transactional data and EGenTxnHarness to control frame invocation.

EGenDriver
EGenDriver comprises the following parts:



EGenDriverCE provides the core functionality necessary to implement a Customer
Emulator.



EGenDriverMEE provides the core functionality necessary to implement a Market
Exchange Emulator.



EGenDriverDM provides the core functionality necessary to implement the DataMaintenance Generator.

EGenDriver provides core transactional functionality (e.g. Transaction Mix and input generation)necessary to implement a Driver.

EGenDriverCE
EGenDriverCE – any and/or all instantiations of the CCE class (see EGenSourceFiles CE.h andCE.cpp).

EGenDriverDM
EGenDriverDM – the single instantiation of the CDM class (see EGenSourceFiles DM.h and DM.cpp).

EGenDriverMEE
EGenDriverMEE – any and/or all instantiations of the CMEE class (see EGenSourceFiles MEE.h andMEE.cpp).

EGenInputFiles
EGenInputFiles is a set of TPC provided text files containing rows of tab-separated data, which areused by various EGen packages as “raw” material for data generation.

EGenLoader
EGenLoader is a binary executable, generated by using the methods described in EGenProjectFileswith source code from EGenSourceFiles, including any extensions by a Test Sponsor (see Clause
5.7.4). When executed, EGenLoader uses EGenInputFiles to produce a set of data that represents theinitial state of the TPC-E database.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 28 of 287

EGenLogger
EGenLogger logs the initial configuration and any re-configuration of EGenDriver and EGenLoader,and compares current configuration with the TPC-E prescribed defaults.

EGenProjectFiles
EGenProjectFiles is a set of TPC provided files used to facilitate building the EGen packages in a Test
Sponsor's environments.

EGenSourceFiles
EGenSourceFiles is the collection of TPC provided C++ source and header files.

EGenTables
EGenSourceFiles contain class definitions that provide abstractions of the TPC-E tables. These tableclasses are known collectively as EGenTables and they encapsulate the functionality needed togenerate the data for each of the TPC-E tables.

EGenValidate
EGenValidate is a binary executable, generated by using methods described in EGenProjectFiles withsource code from EGenSourceFiles. When executed, EGenValidate uses Sponsor provided input tovalidate that the Sponsor's Measurement Interval had compliant Trade-Results per Load Unit.

EGenTxnHarness
EGenTxnHarness defines a set of interfaces that are used to control the execution of, andcommunication of inputs and outputs, of Transactions and Frames.

ENUM
ENUM(m[,n]) or SENUM(m[,n]) means an exact numeric value (unsigned or signed, respectively).
ENUM and SENUM are identical to NUM and SNUM, respectively, except that they must be
implemented using a Native Data Type which provides exact representation of at least n Digits ofprecision after the decimal place.

Executive Summary Statement
The term Executive Summary Statement refers to the Adobe Acrobat PDF file in the
ExecutiveSummaryStatement folder in the FDR. The contents of the Executive Summary Statement are
defined in Clause 9.
F ___________________________FDR
The FDR is a zip file of a directory structure containing the following:
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 29 of 287



A Report in Adobe Acrobat PDF format,



An Executive Summary Statement in Adobe Acrobat PDF format,



An XML document (“ES.xml”) with approximately the same information as in the Executive
Summary Statement,

The Supporting Files consisting of various source files, scripts, and listing files. Requirements for
the FDR file directory structure are described below.

Comment: The purpose of the FDR is to document how a benchmark Result was implemented andexecuted in sufficient detail so that the Result can be reproduced given the appropriate hardware andsoftware products.

FIN_AGG_T
FIN_AGG_T is defined as SENUM(15,2) and is used for holding aggregated financial data such as
revenue figures, valuations, and asset values.

Fixed Space
Fixed Space: any other space used to store static information and indices. It includes all databasestorage space allocated to the test database which does not qualify as either Free Space or Growing
Space.

Fixed Tables
Fixed Tables: These tables always have the same number of rows regardless of the database size andtransaction throughput. For example, TRADE_TYPE has five rows.

Foreign Key
A Foreign Key (FK) is a column or combination of columns used to establish and enforce a link
between the data in two tables. A link is created between two tables by adding the column or columns
that hold one table's Primary Key values to the other table. This column becomes a Foreign Key in thesecond table.

Frame
A Frame is the Sponsor implemented Transaction logic, which is invoked as a unit of execution by the
EGenTxnHarness. The database interactions of a Transaction are all initiated from within its Frames.

Frame Implementation
Frame Implementation – Sponsor provided functionality that accepts inputs from, and provides
outputs to, EGenTxnHarness through a TPC Defined Interface. The Frame Implementation and all
down-stream functional components are responsible for providing the appropriate functionality
outlined in the Transaction Profiles (Clause 3.3).

Free SpaceTPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 30 of 287

Free Space: any space allocated to the test database and available for future use. It includes all
database storage space not already used to store a database entity (e.g., a row, an index, Database
Metadata) or not already used as formatting overhead by the DBMS.

Full Disclosure Report (FDR)
See FDR.

G ___________________________
Growing Space
Growing Space: any space used to store existing rows from the Growing Tables and their associatedUser-Defined Objects. It includes all database storage space that is added to the test database as aresult of inserting a new row in the Growing Tables, such as row data, index data and other overheads
such as index overhead, page overhead, block overhead, and table overhead.

Growing Tables
Growing Tables: These tables each have an initial cardinality that has a defined relationship to thecardinality of the CUSTOMER table. However, the cardinality increases with new growth during thebenchmark run at a rate that is proportional to transaction throughput rates.
H ___________________________
I ___________________________IDENT_T
IDENT_T is defined as NUM(11) and is used to hold non-trade identifiers.

Initial Database Size
Initial Database Size is measured after the database is initially loaded with the data generated by
EGenLoader. Initial Database Size is any space allocated to the test database which is used to store a
database entity (e.g. a row, an index, Database Metadata), or used as formatting overhead by the data
manager.

Initial Trade Days
The Initial Trade Days (ITD) is the number of Business Days used to populate the database. This
population is made of trade data that would be generated by the SUT when running at the Nominal
Throughput for the specified number of Business Days. The number of Initial Trade Days is 300.

ITD
See Initial Trade Days.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 31 of 287

J ___________________________
K __________________________
L __________________________
Load Unit
The size of the CUSTOMER table can be increased in increments of 1000 customers. A set of 1000
customers is known as a Load Unit.

Log Growth
Log Growth: the space needed in the DBMS log files to accommodate the Undo/Redo Log resulting
from executing the Transaction Mix at the Reported Throughput during the period of required
Sustainable performance.
Log Growth = Log-Space-per-Trade-Result * tpsE * Business Day duration in seconds

M ___________________________
Market Exchange Emulator
Another key piece of a compliant TPC-E Driver is the Market Exchange Emulator (MEE). The MEE is
responsible for emulating the stock exchanges: providing services to the brokerage house, performing
requested trades, providing market activity updates, etc. Therefore, the MEE is responsible for thefollowing:

Receiving trade requests and their associated data from the SUT.



Initiating Trade-Result Transactions, sending the associated data to the SUT and measuring theTransaction’s Response Time.



Initiating Market-Feed Transactions, sending the associated data to the SUT and measuring theTransaction’s Response Time.

Comment: The MEE may optionally perform additional operations as well; such as statistical accounting,data logging, etc.

Market Tables
Market Tables: This set includes 11 tables that contain information about companies, markets,
exchanges, and industry sectors.

Market Triggered
Market Triggered: These Transactions simulate the behavior of the market and are triggered by theMarket Exchange Emulator component of the benchmark Driver.

May
The word “may” in the specification means that an item is truly optional.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 32 of 287

Measured Configuration
See System Under Test.

Measured Throughput
The Measured Throughput is computed as the total number of Valid Trade-Result Transactions
within the Measurement Interval divided by the duration of the Measurement Interval in seconds.

Measurement Interval
Measurement Interval: the period of time during Steady State chosen by the Test Sponsor to compute
the Reported Throughput.

MEE
See Market Exchange Emulator

ModifyThe word “Modify” indicates that the content of a TPC-E table column is modified within the Frame.
The content of the table column can only be changed in a Frame where the word “Modify” is specified.
When the original content of the table column must also be referenced or returned before it is modified,a “Reference” or a “Return” access method is also specified.

Must
The word “must” or the terms “required”, “requires”, “requirement” or “shall” in the specification,means that compliance is mandatory.

Must notThe phrase “must not” or the term “shall not” in the specification, means that this is an absoluteprohibition of the specification.
N ___________________________
Native Data TypeA Native Data Type is a built-in data type of the DBMS whose documented purpose is to store data ofa particular type described in the specification. For example, DATETIME must be implemented with abuilt-in data type of the DBMS designed to store date-time information.

Network

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 33 of 287

Network – Sponsor provided functionality that must support communication through an industry
standard communications protocol using a physical means. One outstanding feature of the Connector –Network – Connector communication is that it follows the relevant standards and must imply morethan just an application package. It must be possible to have concurrent use of the means by otherapplications. Physical transport of the data is required and the underlying means of this transport must
be capable of operating over arbitrary globally geographic distances. TPC/IP over a local area network
is an example of an acceptable Network implementation.

Nominal Throughput
The Nominal Throughput of the TPC-E benchmark is defined to be 2.00 Transactions-Per-Second-E(tpsE) for every 1000 customer rows in the Configured Customers.

Non-catastrophic
The term Non-catastrophic as applied to a single failure is one where processing is not interrupted, but
throughput may be degraded and the SUT may no longer be in a durable state until the SUT has
recovered from the failure.

NUM(m[,n])NUM(m[,n]) means an unsigned numeric value with at least m total Digits, of which n Digits are to theright (after) the decimal point. The data type must be able to hold all possible values which can be
expressed as NUM(m[,n]). Omitting n, as in NUM(m), indicates the same as NUM(m,0). NUM must be
implemented using a Native Data Type.

O ___________________________
On-LineA storage device is considered On-Line if it is capable of providing an access time to data, for random
read or update, of one second or less by the Operating System.
Comment: Examples of On-Line storage may include magnetic disks, optical disks, solid-state storage,
or any combination of these, provided that the above mentioned access criteria is met.

Operating System/OS
The term Operating System refers to the program that, after being initially loaded into the computer bya boot program, manages all the other programs in a computer. The Operating System provides asoftware platform on top of which all other programs run. Without the Operating System and the coreservices that it provides no other programs can run and the computer would be non-functional. Other
programs make use of the Operating System by making requests for services through a defined
application program interface (API). All major computer platforms require an Operating System. The
functions and services supplied by an Operating System include but are not limited to the following:Manages a dedicated set of processor and memory resources.



Maintains and manages a file system.



Loads applications into memory.

Ensures that the resources allocated to one application are not used by another application in an
unauthorized manner.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 34 of 287



Determines which applications should run in what order, and how much time should be allowed to
run the application before giving another application a turn to use the systems resources.

Manages the sharing of internal memory among multiple applications.



Handles input and output to and from attached hardware devices such as hard disks, network
interface cards etc.

Some examples of Operating Systems are listed below:
WindowsUnixes (Solaris, AIX)



Linux



MS-DOSMac OSVMS

NetwareP ___________________________
Pacing Delay
Pacing Delay is defined as the total time injected into the Dispatch Time (DTn) that is intended todecrease the rate at which Transactions are submitted to the SUT.

Part Number
See the definition of Part Number in the TPC Pricing Specification.

Performance Metric
The TPC-E Reported Throughput as expressed in tpsE. This is known as the Performance Metric.

Priced Configuration
Priced Configuration: The components to be priced defined in the benchmark specification, including
all hardware, software and maintenance.

Price/Performance Metric
The TPC-E total 3-year pricing divided by the Reported Throughput is price/tpsE. This is also known
as the Price/Performance Metric.

Primary Key
A Primary Key is a single column or combination of columns that uniquely identifies a row. None of
the columns that are part of the Primary Key may be nullable. A table must have no more than one
Primary Key.

ProfileTPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 35 of 287

Profile: the characteristics of a Transaction, as defined by the Pseudo-code and summarized by the
Database Footprint.

Pseudo-code
Pseudo-code is a description of an algorithm that uses the structural conventions of programming
languages, but omits language-specific syntax.
Q ___________________________
R ___________________________
Ramp-down
Ramp-down: the period of time from the end of Steady State to the end of the Test Run.

Ramp-upRamp-up: the period of time from the start of the Test Run to the start of Steady State.

Redundancy Level One
Redundancy Level One (Durable Media Redundancy): Guarantees access to the data on Durable
Media when a single Durable Media failure occurs.

Redundancy Level Three
Redundancy Level Three (Full Redundancy): Includes Redundancy Level Two and guarantees accessto the data on Durable Media when a single failure occurs within the Durable Media system,
including communications between Tier B and the Durable Media system.

Redundancy Level Two
Redundancy Level Two (Durable Media Controller Redundancy): Includes Redundancy Level One
and guarantees access to the data on Durable Media when a single failure occurs in the storage
controller used to satisfy the redundancy level or in the communication media between the storage
controller and the Durable Media.

Reference
The word “Reference” indicates that the TPC-E table column is identified in the database and thecontent is accessed within the Frame without passing the content of the table column to the
EGenTxnHarness.

Referential Integrity
Referential Integrity preserves the relationship of data between tables, by restricting actions performedon Primary Keys and Foreign Keys in a table.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 36 of 287

Remove
The word “Remove” indicates that a number of rows are removed from the TPC-E table specified by
the Database Footprint. Table row(s) can only be removed in a Frame where the word “Remove” isspecified. The number of rows that are removed is specified in the second column of the Database
Footprint with either “# row” for a fixed number of rows or “row(s)” for an unspecified number ofrows.

Report
The term Report refers to the Adobe Acrobat PDF file in the Report folder in the FDR. The contents of
the Report are defined in Clause 9.

Reported
The term Reported refers to an item that is part of the FDR.

Reported Throughput
The Performance Metric reported by TPC-E is the Reported Throughput. The name of the metric used
for the Reported Throughput of the SUT is tpsE. The value of this metric is based on the Measured
Throughput and is bound by the requirements of Clause 6.7.1.2.

Response TimeThe Response Time (RT) is defined by:
RTn = eTn - sTn
where:
sTn and eT n are measured at the Driver;sTn =time measured before the first byte of input data of the Transaction is sent by the Driverto the SUT; andeTn =time measured after the last byte of output data from the Transaction is received by the
Driver from the SUT.
Comment: The resolution of the time stamps used for measuring Response Time must be at least 0.01

seconds.

Results
TPC-E Results are the Performance Metric, Price/Performance Metric.

Return
The word “Return” indicates that the TPC-E table column is referenced and that its content is retrieved
from the database and passed to the EGenTxnHarness. The table column must be referenced in thesame Frame where the word “Return” is specified. The content of the table column can only be passed
to subsequent Frames via the input and output parameters specified in the Frame parameters.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 37 of 287

RollbackThe word “Rollback” indicates that the specified Frame contains a control operation that rolls back the
Database Transaction. The explicit rolling back of a Database Transaction can only occur in a Frame
where the word “Rollback” is specified.

RT
See Response Time.

S ___________________________
S_COUNT_T
S_COUNT_T is defined as NUM(12) and is used for holding the aggregate count of shares used inmany tables.

S_PRICE_T
S_PRICE_T is defined as ENUM(8,2) and is used for holding the value of a share price.

S_QTY_T
S_QTY_T is defined as SNUM(6) and is used for holding the quantity of shares per individual trade.

Scale Factor
The Scale Factor is the number of required customer rows per single Transactions-Per-Second-E(tpsE). The Scale Factor for Nominal Throughput is 500.

Scaling Tables
Scaling Tables: These tables each have a defined cardinality that has a constant relationship to thecardinality of the CUSTOMER table. Transactions may update rows from these tables, but the table
sizes remain constant.

SENUM
ENUM(m[,n]) or SENUM(m[,n]) means an exact numeric value (unsigned or signed, respectively).
ENUM and SENUM are identical to NUM and SNUM, respectively, except that they must be
implemented using a Native Data Type which provides exact representation of at least n Digits ofprecision after the decimal place.

SessionSee Database Session.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 38 of 287

SF
See Scale Factor.

ShouldThe word “should” or the adjective “recommended”, mean that there might exist valid reasons inparticular circumstances to ignore a particular item, but the full implication must be understood andweighed before choosing a different course.

Should not
The phrase “should not”, or the phrase “not recommended”, means that there might exist valid reasonsin particular circumstances when the particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed before implementing any behavior
described with this label.

SNUM
SNUM(m[,n]) is identical to NUM(m[,n]) except that it can represent both positive and negative values.
SNUM must be implemented using a Native Data Type.
Comment: A SNUM data type may be used (at the Sponsor’s discretion) anywhere a NUM data type is

specified.

SponsorSee Test Sponsor.

Start
The word “Start” indicates that the specified Frame contains a control operation that starts a Database
Transaction. The start of a Database Transaction can only occur in a Frame where the word “Start” isspecified.

Steady State
Steady State: the period of time from the end of the Ramp-up to the start of the Ramp-down.

Substitution
Substitution is defined as a deliberate act to replace components of the Priced Configuration by the
Test Sponsor as a result of failing the availability requirements of the TPC Pricing Specification orwhen the Part Number for a component changes.

Supporting Files
Supporting Files refers to the contents of the SupportingFiles folder in the FDR. The contents of thisfolder, consisting of various source files, scripts, and listing files, are defined in Clause 9.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 39 of 287

Sustainable
Sustainable: the performance over a given period of time (computed as the average throughput overthat time) shows no significant variations.

SUT
See System Under Test.

System Under Test
System Under Test (SUT) – is defined to be the sum of Tier A and Tier B.

T ___________________________
Test Sponsor
The Test Sponsor is the company officially submitting the Result with the FDR and will be charged thefiling fee. Although multiple companies may sponsor a Result together, for the purposes of the TPC’s
processes the Test Sponsor must be a single company. A Test Sponsor need not be a TPC member. The
Test Sponsor is responsible for maintaining the FDR with any necessary updates or corrections. The
Test Sponsor is also the name used to identify the Result.

Test Run
Test Run: the entire period of time during which Drivers submit and the SUT completes Transactions
other than Trade-Cleanup.

Test Run Graph
A graph of the Trade-Results per second averaged over one minute versus elapsed wall clock timemeasured in minutes must be reported for the entire Test Run. The x-axis represents the elapsed timefrom the Test Run start. The y-axis represents the total number of Trade-Result Transactions thatcomplete within each one-minute interval divided by 60. A plot interval size of 1 minute must be used.
The Ramp-up, Steady State, Measurement Interval, and Ramp-down must be identified on the graph.
The Test Run Graph must be reported in the Report.

Tier A
Tier A – is defined to be all hardware and software needed to implement the down-stream Connector,
EGenTxnHarness, Frame Implementation and Database Interface functional components.

Tier B
Tier B – is defined to be all hardware and software needed to implement the Database Server
functional component. This includes data storage media sufficient to satisfy the initial database
population requirements of clause 2.6.1 and the Business Day growth requirements of clause 6.6.6.4
and clause 6.6.6.5.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 40 of 287

TPC-Certified Auditor
The term TPC-Certified Auditor is used to indicate that the TPC has reviewed the qualification of the
Auditor and has certified his/her ability to verify that benchmark Results are in compliance with thisspecification. (Additional details regarding the Auditor certification process and the audit process canbe found in Section 9 of the TPC Policy document.)

TPC Defined Interface
A TPC Defined Interface is a C++ class member which is designed to exchange data (and transfer
execution control) between the Sponsor-provided Driver/SUT code and the TPC-provided Driver/SUT
code.

TRADE_T
TRADE_T is defined as NUM(15) and is used to hold trade identifiers.

Transaction(s)The TPC-E Transactions are at the heart of the workload. The core of each Transaction runs on the
Database Server, but the logic of the Transaction interacts with several components of the benchmark
environment.
A Transaction is composed of Harness-code and of the invocation of one or more Frames. The TradeCleanup Transaction is an exception. Sponsors may but do not have to run the Trade-Cleanup
Transaction from EGenTxnHarness.

Transaction Mix
The Transaction Mix is composed of all Customer Initiated, Brokerage Initiated and Market Triggered
Transactions.

Tunable Parameters
Tunable Parameters are parameters, switches or flags that can be changed to modify the behavior of
the product. Tunable Parameters apply to both hardware and software and are not limited to thoseparameters intended for use by customers.
U ___________________________
U*x
U*x is used in this specification to refer to various UNIX and Linux flavors (e.g. UNIX, Linux, AIX,
Solaris).

Undo/Redo Log
Undo/Redo Log: records all changes made in data files. The Undo/Redo Log makes it possible to replay
all the actions executed by the Database Management System. If something happens to one of the data
files, a backed up data file can be restored and the Undo/Redo Log that was written since the backup
can be played and applied which brings the data file to the state it had before it became unavailable.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 41 of 287

User-Defined Object
Any object defined in the database is considered a User-Defined Object, except for the following:a TPC-E Table (see clause 2.2.3)



a required Primary Key (see clause 2.2.3.1)



a required Foreign Key (see clause 2.2.3.2)



a required constraint (see clause 2.2.3.3)

Database Metadata

V ___________________________
Valid Transaction
The term Valid Transaction refers to any Transaction for which input data has been sent in full by the
Driver, whose processing has been successfully completed on the SUT and whose correct output data
has been received in full by the Driver.

VALUE_T
VALUE_T is defined as SENUM(10,2) and is used for holding non-aggregated transaction and security
related values such as cost, dividend, etc.

Vulnerable Storage Component
Vulnerable Storage Component – any Field Replaceable Unit (FRU) within the SUT that:

Has volatile storage (is not Durable Media)

Participates in implementing the Commit control operation

W ___________________________
X ___________________________
Y ___________________________
Z ___________________________TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 42 of 287

1.2

Business and Application Environment
TPC Benchmark™ E is composed of a set of transactional operations designed to exercise system
functionalities in a manner representative of complex OLTP application environments. Thesetransactional operations have been given a life-like context, portraying the activity of a brokerage firm,
to help users relate intuitively to the components of the benchmark. The TPC-E workload is centeredon the activity of processing brokerage trades and uses a schema, which is logically divided into four
sets of tables.
TPC-E models the activity of brokerage firm that must manage customer accounts, execute customer
trade orders, and be responsible for the interactions of customers with financial markets. TPC-E does
not attempt to be a model of how to build an actual application. The following diagram illustrates thetransaction flow of the business model portrayed in the benchmark:CustomerMarketMarketTriggeredTransactions

Customer
Initiated
Transactions
Brokerage

Figure 1.a - Business Model Transaction Flow
The purpose of a benchmark is to reduce the diversity of operations found in a production application,
while retaining the application's essential performance characteristics so that the workload can be
representative of a production system. A large number of functions have to be performed to manage aproduction brokerage system. Many of these functions are not of primary interest for performance
analysis, since they are proportionally small in terms of system resource utilization or in terms offrequency of execution. Although these functions are vital for a production system, they merely create
excessive diversity in the context of a standard benchmark and have been omitted in TPC-E.
The Company portrayed by the benchmark is a brokerage firm with customers who generatetransactions related to trades, account inquiries, and market research. The brokerage firm in turninteracts with financial markets to execute orders on behalf of the customers and updates relevant
account information.
The number of customers defined for the brokerage firm can be varied to represent the workloads ofdifferent size businesses.
The TPC-E benchmark is composed of a set of transactions that are executed against three sets ofdatabase tables that represent market data, customer data, and broker data. A fourth set of tables
contains generic dimension data such as zip codes. The following diagram illustrates the key
components of the environment:

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 43 of 287

Customers

Brokers

MarketInvoke the following transactions …
READ-WRITE•Market-Feed•Trade-Order•Trade-Result•Trade-Update

READ-ONLY•Broker-Volume•Customer-Position•Market-Watch•Security-Detail•Trade-Lookup•Trade-Status… against the following data

Customer Data

Brokerage Data

Market Data

Figure 1.b - Application Components
The benchmark has been reduced to simplified form of the application environment. To measure theperformance of the OLTP system, a simple Driver generates Transactions and their inputs, submits
them to the System Under Test, and measures the rate of completed Transactions being returned. To
simplify the benchmark and focus on the core transactional performance, all application functions
related to user interface and display functions have been excluded from the benchmark. The System
Under Test is focused on portraying the components found on the server side of a transaction monitor
or application server.

1.3

Transaction Summary

1.3.1

Broker-Volume
The Broker-Volume Transaction is designed to emulate a brokerage house’s “up-to-the-minute”
internal business processing. An example of a Broker-Volume Transaction would be a manager
generating a report on the current performance potential of various brokers.

1.3.2

Customer-Position
The Customer-Position Transaction is designed to emulate the process of retrieving the customer’s
profile and summarizing their overall standing based on current market values for all assets. This isrepresentative of the work performed when a customer asks the question “What am I worth today?”

1.3.3

Market-Feed
The Market-Feed Transaction is designed to emulate the process of tracking the current market
activity. This is representative of the brokerage house processing the “ticker-tape” from the market
exchange.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 44 of 287

1.3.4Market-Watch
The Market-Watch Transaction is designed to emulate the process of monitoring the overall
performance of the market by allowing a customer to track the current daily trend (up or down) of acollection of securities. The collection of securities being monitored may be based upon a customer’scurrent holdings, a customer’s watch list of prospective securities, or a particular industry.

1.3.5

Security-Detail
The Security-Detail Transaction is designed to emulate the process of accessing detailed information ona particular security. This is representative of a customer doing research on a security prior to making adecision about whether or not to execute a trade.

1.3.6

Trade-Lookup
The Trade-Lookup Transaction is designed to emulate information retrieval by either a customer or abroker to satisfy their questions regarding a set of trades. The various sets of trades are chosen such thatthe work is representative of:

1.3.7



performing general market analysis

reviewing trades for a period of time prior to the most recent account statementanalyzing past performance of a particular security

analyzing the history of a particular customer holding

Trade-Order
The Trade Order Transaction is designed to emulate the process of buying or selling a security by a
Customer, Broker, or authorized third-party. If the person executing the trade order is not the accountowner, the Transaction will verify that the person has the appropriate authorization to perform thetrade order. The Transaction allows the person trading to execute buys at the current market price,sells at the current market price, or limit buys and sells at a requested price. The Transaction also
provides an estimate of the financial impact of the proposed trade by providing profit/loss data, tax
implications, and anticipated commission fees. This allows the trader to evaluate the desirability of the
proposed security trade before either submitting or canceling the trade.

1.3.8

Trade-Result
The Trade-Result Transaction is designed to emulate the process of completing a stock market trade.
This is representative of a brokerage house receiving from the market exchange the final confirmationand price for the trade. The customer’s holdings are updated to reflect that the trade has completed.
Estimates generated when the trade was ordered for the broker commission and other similar
quantities are replaced with the actual numbers and historical information about the trade is recorded
for later reference.

1.3.9

Trade-Status
The Trade-Status Transaction is designed to emulate the process of providing an update on the statusof a particular set of trades. It is representative of a customer reviewing a summary of the recent
trading activity for one of their accounts.

1.3.10Trade-Update
The Trade-Update Transaction is designed to emulate the process of making minor corrections or
updates to a set of trades. This is analogous to a customer or broker reviewing a set of trades, anddiscovering that some minor editorial corrections are required. The various sets of trades are chosensuch that the work is representative of:

reviewing general market trends
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 45 of 287

1.3.11reviewing trades for a period of time prior to the most recent account statementreviewing past performance of a particular security

Data-Maintenance
The Data-Maintenance Transaction is designed to emulate the periodic modifications to data that ismainly static and used for reference. This is analogous to updating data that seldom changes.

1.3.12

Trade-Cleanup
The Trade-Cleanup Transaction is used to cancel any pending or submitted trades from the database.

1.4

Model Description

1.4.1

Entity Relationships

1.4.1.1

Trading in TPC-E is done by Accounts. Accounts belong to Customers. Customers are serviced by
Brokers. Accounts trade Securities that are issued by Companies.

1.4.1.2

The total set of Securities that can be traded and the total set of Companies that issue Securities scales
along with the number of Customers. For each unit of 1,000 Customers, there are 685 Securities and 500
Companies (with Companies issuing 1 to 5 Securities, mostly common shares, but some preferred aswell).

1.4.1.3

All Companies belong to one of the 102 Industries. Each Industry belongs to one of the 12 market
Sectors.

1.4.1.4

Each Account picks its average of ten Securities to trade from across the entire range of Securities.

1.4.1.5

Securities to be traded can be identified by the security symbol or by the company name and security
issue.

1.4.2

Differences between Customer Tiers

1.4.2.1

The basic scaling unit of a TPC-E database is a set of 1,000 Customers. 20% of each 1,000 Customers
belong to Tier 1, 60% to Tier 2, and 20% to Tier 3. Tier 2 Customers trade twice as often as Tier 1
Customers. Tier 3 Customers trade three times as often as Tier 1 Customers. In general, customer
trading is non-uniform by tier within each set of 1,000 Customers.

1.4.2.2

Tier 1 Customers have 1 to 4 Accounts (average 2.5). Tier 2 Customers have 2 to 8 Accounts (average5.0). Tier 3 Customers have 5 to 10 Accounts (average 7.5). Overall, there is an average of five Accounts
per Customer.

1.4.2.3

The minimum and maximum number of Securities that are traded by each Account varies by Customer
Tier and by the number of Accounts for each Customer. The average number of Securities traded per
Account is ten (so the average number of Securities traded per Customer is fifty). For each Account, thesame set of Securities is traded for both the initial database population and for any Test Run.

1.4.3

Customer Partitioning

1.4.3.1

TPC-E scales with Customers. It is conceivable that Customer information could be partitioned into
groups of related Customers. This is called Customer Partitioning. The advantage of Customer
Partitioning is that it increases locality of reference within each sub-group of Customers. Transactions
can be directed to a subset of Customers or to the entire set of Customers, in a defined proportion.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 46 of 287

1.4.4

Trade Types

1.4.4.1

Trade requests come in two basic flavors: Buy (50%) and Sell (50%). Those are further broken down into
Trade Types, depending on whether the request was a Market Order (60%) or a Limit Order (40%).

1.4.4.2

For Market Orders, the two trade types are Market-Buy (30%) and Market-Sell (30%). For Limit Orders,
the three trade types are Limit-Buy (20%), Limit-Sell (10%) and Stop-Loss (10%).

1.4.4.3

Market-Buy and Market-Sell are trade requests to buy and sell immediately at the current market price,whatever price that may be. Limit-Buy is a request to buy only when the market price is at or below thespecified limit price. Limit-Sell is a request to sell only when the market price is at or above thespecified limit price. Stop-Loss is a request to sell only when (or if) the market price drops to or below
the specified limit price.

1.4.4.4

If the specified limit price has not been reached when the Limit Order is requested, it is considered an
Out-of-the-Money request and remains “Pending” until the specified limit price is reached. Reaching
the limit price is guaranteed to occur within 15 minutes based on EGenDriverMEE implementation
details. The act of noticing that a “Pending” limit request has reached or exceeded its specified limit
price and submitting it to the market exchange to be traded is known as triggering of the pending limit
order.

1.4.5

Effects of Trading on Holdings

1.4.5.1

For a given account and security, holdings will be either all long (positive quantities) or all short(negative quantities).

1.4.5.2

Long positions represent shares of the security that were bought (purchased and paid for) by thecustomer for the account. The customer owns the shares of the security and may sell them at a latertime (hopefully, for a higher price).

1.4.5.3

Short positions represent shares of the security that were borrowed from the broker (or Brokerage) andwere sold by the customer for the account. In the short sale case, the customer has received the funds
from that sell, but still has to cover the sell by later purchasing an equal number of shares (hopefully ata lower price) from the market and returning those shares to the broker.

1.4.5.4

Before EGenLoader runs, there are no trades and no positions in any security for any account.
EGenLoader simulates running the benchmark for three hundred Business Days of initial trading, sothat the initial database will be ready for benchmark execution.

1.4.5.5

If the first trade for a security in an account is a buy, a long position will be established (positive
quantity in HOLDING row). Subsequent buys in the same account for the same security will add
holding rows with positive quantities. Subsequent sells will reduce holding quantities or delete holding
rows to satisfy the sell trade. All holdings may be eliminated, in which case the position becomes
empty. If the sell quantity still is not satisfied, the position changes from long to short (see below).

1.4.5.6

If the first trade for a security in an account is a sell, a short position will be established (negative
quantity in HOLDING row). Subsequent sells in the same account for the same security will add
holding rows with negative quantities. Subsequent buys will reduce holding quantities (toward zero)or delete holding rows to satisfy the buy trade. All holdings may be eliminated, in which case theposition becomes empty. If the buy quantity still is not satisfied, the position changes from short tolong.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 47 of 287

CLAUSE 2 -- DATABASE DESIGN, SCALING & POPULATION
2.1

Introduction
The TPC-E database is defined to consist of 33 separate and individual tables. The database schema isorganized into four sets of tables:Customer Tables: This set includes 9 tables that contain information about the customers of thebrokerage firm.



Broker Tables: This set includes 9 tables that contain information about the brokerage firm andbroker related data.

Market Tables: This set includes 11 tables that contain information about companies, markets,
exchanges, and industry sectors.



Dimension Tables: This set includes 4 dimension tables that contain common information such asaddresses and zip codes.

The relationship between the tables and the requirements governing their use are outlined in theremaining sections of Clause 2.
2.1.1

Definitions

2.1.1.1

A Primary Key is a single column or combination of columns that uniquely identifies a row. None of
the columns that are part of the Primary Key may be nullable. A table must have no more than one
Primary Key.

2.1.1.2

A Foreign Key (FK) is a column or combination of columns used to establish and enforce a link
between the data in two tables. A link is created between two tables by adding the column or columns
that hold one table's Primary Key values to the other table. This column becomes a Foreign Key in thesecond table.

2.2

TPC-E Database Schema and Table Definitions
Details of the TPC-E database schema, the data type requirements, the required structure of eachindividual table, the entity relationship between tables and the individual column restrictions aredefined in this clause.

2.2.1

Data Type Definitions

2.2.1.1

A Native Data Type is a built-in data type of the DBMS whose documented purpose is to store data ofa particular type described in the specification. For example, DATETIME must be implemented with abuilt-in data type of the DBMS designed to store date-time information.

2.2.1.2

CHAR(n) means a character string that can hold up to n single-byte characters. Strings may be paddedwith spaces to the maximum length. CHAR(n) must be implemented using a Native Data Type.

2.2.1.3

NUM(m[,n]) means an unsigned numeric value with at least m total Digits, of which n Digits are to
the right (after) the decimal point. The data type must be able to hold all possible values which can be
expressed as NUM(m[,n]). Omitting n, as in NUM(m), indicates the same as NUM(m,0). NUM must be
implemented using a Native Data Type.

2.2.1.4

SNUM(m[,n]) is identical to NUM(m[,n]) except that it can represent both positive and negativevalues. SNUM must be implemented using a Native Data Type.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 48 of 287

Comment: A SNUM data type may be used (at the Sponsor’s discretion) anywhere a NUM data type is

specified.
2.2.1.5

ENUM(m[,n]) or SENUM(m[,n]) means an exact numeric value (unsigned or signed, respectively).
ENUM and SENUM are identical to NUM and SNUM, respectively, except that they must be
implemented using a Native Data Type which provides exact representation of at least n Digits ofprecision after the decimal place.
Comment: A numeric data type provides either exact or approximate representation of numeric values.

For example, INTEGER and DECIMAL are exact numeric data types and REAL and FLOAT areapproximate numeric data types (based on ANSI SQL definitions).
2.2.1.6

BOOLEAN is a data type capable of holding at least two distinct values that represent FALSE and
TRUE.
Comment: The convention in this document, as well as the implementation of EGen, is that the value

zero (0) denotes FALSE and the value one (1) denotes TRUE.
2.2.1.7

DATE represents the data type of date with a granularity of a day and must be able to support therange of January 1, 1800 to December 31, 2199, inclusive. DATE must be implemented using a Native
Data Type.
Comment: A time component is not required but may be implemented.

2.2.1.8

DATETIME represents the data type for a date value that includes a time component. The datecomponent must meet all requirements of the DATE data type. The time component must be capable ofrepresenting the range of time values from 00:00:00 to 23:59:59. Fractional seconds may be
implemented, but are not required. DATETIME must be implemented using a Native Data Type.

2.2.1.9

BLOB(n) is a data type capable of holding a variable length binary object of n bytes.

2.2.1.10

BLOB_REF is a data type capable of referencing a BLOB(n) object that is stored outside the table on the
SUT.

2.2.2

Meta-type Definitions
The following meta-types are defined for ease of notation. These meta-types may be implemented
using the underlying data type on which each is defined. There is no requirement to implement themeta-types as user-defined types in the DBMS. A meta-type may be implemented using a user-defined
type in the DBMS as long as the user-defined type incorporates a Native Data Type where required
and inherits the properties of that Native Data Type.

2.2.2.1

IDENT_T is defined as NUM(11) and is used to hold non-trade identifiers.

2.2.2.2

TRADE_T is defined as NUM(15) and is used to hold trade identifiers.
Trade identifiers have the following characteristics:


They must be unique.



They may be sparse.

At load time they are generated by EGenLoader.

At run time they are generated by Sponsor provided code.

The EGenLoader code will not associate trade identifiers with Date/time or customer identifier or
account identifiers. No assumptions may be made about trade identifier sequencing.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 49 of 287

2.2.2.3

FIN_AGG_T is defined as SENUM(15,2) and is used for holding aggregated financial data such as
revenue figures, valuations, and asset values.

2.2.2.4

S_PRICE_T is defined as ENUM(8,2) and is used for holding the value of a share price.

2.2.2.5

S_COUNT_T is defined as NUM(12) and is used for holding the aggregate count of shares used inmany tables.

2.2.2.6

S_QTY_T is defined as SNUM(6) and is used for holding the quantity of shares per individual trade.

2.2.2.7

BALANCE_T is defined as SENUM(12,2) and is used for holding aggregate account and transaction
related values such as account balances, total commissions, etc.

2.2.2.8

VALUE_T is defined as SENUM(10,2) and is used for holding non-aggregated transaction and security
related values such as cost, dividend, etc.

2.2.3

General Schema Items
The following table lists the category, prefix and the name for all TPC-E required tables in thebenchmark.
Category

CUSTOMERBROKER

MARKET

Table Name

Table Prefix

Definition

ACCOUNT_PERMISSION

AP_

Clause 2.2.4.1

CUSTOMERC_

Clause 2.2.4.2

CUSTOMER_ACCOUNTCA_Clause 2.2.4.3

CUSTOMER_TAXRATECX_Clause 2.2.4.4

HOLDINGH_

Clause 2.2.4.5

HOLDING_HISTORY

HH_

Clause 2.2.4.6

HOLDING_SUMMARY

HS_

Clause 2.2.4.7

WATCH_ITEM

WI_

Clause 2.2.4.8

WATCH_LIST

WL_

Clause 2.2.4.9

BROKER

B_

Clause 2.2.5.1

CASH_TRANSACTION

CT_

Clause 2.2.5.2

CHARGECH_

Clause 2.2.5.3

COMMISSION_RATE

CR_

Clause 2.2.5.4

SETTLEMENTSE_

Clause 2.2.5.5

TRADE

T_

Clause 2.2.5.6

TRADE_HISTORY

TH_

Clause 2.2.5.7

TRADE_REQUESTTR_

Clause 2.2.5.8

TRADE_TYPE

TT_

Clause 2.2.5.9

COMPANY

CO_

Clause 2.2.6.1

COMPANY_COMPETITORCP_

Clause 2.2.6.2

DAILY_MARKET

DM_

Clause 2.2.6.3

EXCHANGE

EX_

Clause 2.2.6.4

FINANCIALFI_

Clause 2.2.6.5

INDUSTRYIN_

Clause 2.2.6.6

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 50 of 287

DIMENSIONLAST_TRADE

LT_

Clause 2.2.6.7

NEWS_ITEM

NI_

Clause 2.2.6.8

NEWS_XREF

NX_

Clause 2.2.6.9

SECTORSC_

Clause 2.2.6.10

SECURITYS_

Clause 2.2.6.11

ADDRESSAD_

Clause 2.2.7.1

STATUS_TYPE

ST_

Clause 2.2.7.2

TAXRATE

TX_

Clause 2.2.7.3

ZIP_CODE

ZC_

Clause 2.2.7.4

2.2.3.1

The Primary Key references defined in this section must be maintained by the database during a Test
Run. The Primary Keys are marked with PK or PK+ in the Relations field for each table definition. PK
indicates that the column is the table’s Primary Key while PK+ indicates that the column is part of acomposite (multi-column) Primary Key.

2.2.3.2

The Foreign Key references defined in this section must be maintained by the database during a Test
Run. The Foreign Keys are marked with FK () or FK+ () in the Relations field for each table definition.
FK () indicates a single-column Foreign Key while FK+ () indicates that the column is part of acomposite (multi-column) Foreign Key. The table prefix enclosed in the parenthesis indicates thetarget table for the Foreign Key reference.

2.2.3.3

The constraints defined in this section must be enforced by the database during a Test Run. The
constraints are listed in the Constraints column for each table definition.
Comment: Unless a Not Null constraint is present, a column must allow Null.

2.2.3.4

For each TPC-E required table, the columns can be implemented in any order, using any physicalrepresentation available from the tested system that satisfies the schema data type requirements.

2.2.4

Customer Tables
These groups of tables contain information about customer related data.

2.2.4.1

ACCOUNT_PERMISSION

This table contains information about the access the customer or an individual other than the customer
has to a given customer account. Customer accounts may have trades executed on them by more than
one person.
Table Prefix: AP_
Column Name

Data TypeConstraints

AP_CA_ID

IDENT_T

Not Null

AP_ACL

CHAR(4)

Not Null

AP_TAX_ID

CHAR(20)

Not Null

AP_L_NAME

CHAR(25)

Not Null

RelationsPK+
FK (CA_)

Description
Customer account identifier.
Access Control List defining thepermissions the person has on thecustomer account.

PK+

Tax identifier of the person with accessto the customer account.
Last name of the person with access tothe customer account.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 51 of 287

AP_F_NAME

2.2.4.2

CHAR(20)First name of the person with access tothe customer account.

Not Null

CUSTOMER

This table contains information about the customers of the brokerage firm.
Table Prefix: C_

2.2.4.3

Column Name

Data TypeConstraints

Relations

Description

C_ID

IDENT_T

Not NullPK

Customer identifier, used internally to linkcustomer information.

C_TAX_ID

CHAR(20)

Not Null

C_ST_ID

CHAR(4)

Not Null

C_L_NAME

CHAR(25)

Not NullPrimary Customer's last name.

C_F_NAME

CHAR(20)

Not NullPrimary Customer's first name.

C_M_NAME

CHAR(1)Primary Customer's middle name initial

C_GNDR

CHAR(1)

Gender of the primary customer. Validvalues ‘M’ for male or ‘F’ for Female.

Customer’s tax identifier, used externallyon communication to the customer. Is
alphanumeric.
FK (ST_)

Customer status type identifier. Identifies
if this customer is active or not.

Customer tier: tier 1 accounts are charged
highest fees, tier 2 accounts are charged
medium fees, and tier 3 accounts have thelowest fees.

Not Null

C_TIER

NUM(1)

C_DOB

DATE

Not Null

C_AD_ID

IDENT_T

Not Null

C_CTRY_1

CHAR(3)

Country code for Customer's phone 1.

C_AREA_1

CHAR(3)

Area code for customer’s phone 1.

C_LOCAL_1

CHAR(10)

Local number for customer’s phone 1.

C_EXT_1

CHAR(5)Extension number for Customer’s phone 1.

C_CTRY_2

CHAR(3)

Country code for Customer's phone 2.

C_AREA_2

CHAR(3)

Area code for Customer’s phone 2.

C_LOCAL_2

CHAR(10)

Local number for Customer’s phone 2.

C_EXT_2

CHAR(5)Extension number for Customer’s phone 2.

C_CTRY_3

CHAR(3)

Country code for Customer's phone 3.

C_AREA_3

CHAR(3)

Area code for Customer’s phone 3.

C_LOCAL_3

CHAR(10)

Local number for Customer’s phone 3.

C_EXT_3

CHAR(5)Extension number for Customer’s phone 3.

C_EMAIL_1

CHAR(50)

Customer's e-mail address 1.

C_EMAIL_2

CHAR(50)

Customer's e-mail address 2.

in 1,2,3

Customer’s date of birth.
FK (AD_)

Address identifier of the customer's
address.

CUSTOMER_ACCOUNTThe CUSTOMER_ACCOUNT table contains account information related to accounts of each customer.
Table Prefix: CA_
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 52 of 287

2.2.4.4

Column Name

Data TypeConstraints

Relations

Description

CA_ID

IDENT_T

Not NullPK

Customer account identifier.

CA_B_ID

IDENT_T

Not Null

FK (B_)

Broker identifier of the broker who
manages this customer account.

CA_C_ID

IDENT_T

Not NullFK (C_)

Customer identifier of the customer who
owns this account.

CA_NAMECHAR(50)

Name of customer account. Example,"Trish Hogan 401(k)".

CA_TAX_ST

NUM(1)Tax status of this account: 0 means thisaccount is not taxable, 1 means thisaccount is taxable and tax must be
withheld, 2 means this account is taxable
and tax does not have to be withheld.

CA_BALBALANCE_T

Not Null
in 0,1,2

Not Null

Account’s cash balance.

CUSTOMER_TAXRATE

The table contains two references per customer into the TAXRATE table. One reference is forstate/province tax; the other one is for national tax. The TAXRATE table contains the actual tax rates.
Table Prefix: CX_

2.2.4.5

Column Name

Data TypeConstraints

CX_TX_ID

CHAR(4)

Not Null

CX_C_ID

IDENT_T

Not Null

RelationsPK+
FK (TX_)PK+
FK (C_)

Description
Tax rate identifier.
Customer identifier of a customer thatmust pay this tax rate.

HOLDING

The table contains information about the customer account’s security holdings.
Table Prefix: H_

2.2.4.6

Column Name

Data TypeConstraints

H_T_IDTRADE_T

Not Null

H_CA_ID

IDENT_T

Not Null

FK+ (HS_)

Customer account identifier.

H_S_SYMB

CHAR(15)

Not Null

FK+ (HS_)

Symbol for the security held.

H_DTS

DATETIME

Not Null

H_PRICES_PRICE_T

H_QTY

S_QTY_T

Not Null>0
Not Null

RelationsPK
FK (T_)

Description
Trade Identifier of the trade.

Date this security was purchased or sold.
Unit purchase price of this security.
Quantity of this security held.

HOLDING_HISTORY

The table contains information about holding positions that were inserted, updated or deleted andwhich trades made each change.
Table Prefix: HH_

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 53 of 287

Column Name

2.2.4.7

Data TypeConstraints

RelationsPK+

Description
Trade Identifier of the trade thatoriginally created the holding row. Thisis a Foreign Key to the TRADE table
rather then the HOLDING table because
the HOLDING row could be deleted.

HH_H_T_ID

TRADE_T

Not Null

HH_T_ID

TRADE_T

Not Null

HH_ BEFORE_QTY

S_QTY_T

Not NullQuantity of this security held before themodifying trade. On initial insertion,
HH_BEFORE_QTY is 0.

HH_ AFTER_QTY

S_QTY_T

Not NullQuantity of this security held after themodifying trade. If the HOLDING row
gets deleted by the modifying trade,then HH_AFTER_QTY is 0.

FK (T_)PK+
FK (T_)

Trade Identifier of the current trade (theone that last inserted, updated or deleted
the holding identified by HH_H_T_ID).

HOLDING_SUMMARY

The table contains aggregate information about the customer account’s security holdings.
Table Prefix: HS_
Column Name

Data TypeConstraints

HS_CA_ID

IDENT_T

Not Null

HS_S_SYMBCHAR(15)

Not Null

HS_ QTY

S_QTY_T

Not Null

RelationsPK+
FK (CA_)PK+
FK (S_)

Description
Customer account identifier.
Symbol for the security held.
Total quantity of this security held.

Comment: HOLDING_SUMMARY may be implemented as a view on HOLDING, in which case the

HOLDING Foreign Key references to HOLDING_SUMMARY are automatically met. However, the
HOLDING_SUMMARY Foreign Key references to CA_ and S_ must then be adopted and met by
HOLDING.
2.2.4.8

WATCH_ITEM

The table contains list of securities to watch for a watch list.
Table Prefix: WI_

2.2.4.9

Column Name

Data TypeConstraints

WI_WL_ID

IDENT_T

Not Null

WI_S_SYMBCHAR(15)

Not Null

RelationsPK+
FK (WL_)PK+
FK (S_)

Description
Watch list identifier.
Symbol of the security to watch.

WATCH_LIST

The table contains information about the customer who created this watch list.
Table Prefix: WL_
Column Name

Data TypeConstraints

Relations

Description

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 54 of 287

2.2.5WL_ID

IDENT_T

Not NullPK

Watch list identifier.

WL_C_ID

IDENT_T

Not NullFK (C_)

Identifier of customer who created thiswatch list.

Broker Tables
This group of tables contains data related to the brokerage firm and brokers.

2.2.5.1

BROKER

The table contains information about brokers.
Table Prefix: B_

2.2.5.2

Column Name

Data TypeConstraints

Relations

Description

B_ID

IDENT_T

Not NullPK

Broker identifier.

B_ST_ID

CHAR(4)

Not Null

FK (ST_)

Broker status type identifier; identifies if
this broker is active or not.

B_NAME

CHAR(49)

Not NullBroker's name.

B_NUM_TRADES

NUM(9)

Not NullNumber of trades this broker has
executed so far.

B_COMM_TOTALBALANCE_T

Not NullAmount of commission this broker has
earned so far.

CASH_TRANSACTION

The table contains information about cash transactions.
Table Prefix: CT_

2.2.5.3

Column Name

Data TypeConstraints

Relations

CT_T_ID

TRADE_T

Not Null

CT_DTSDATETIME

Not NullDate and time stamp of when thetransaction took place.

CT_AMT

VALUE_T

Not NullAmount of the cash transaction.

CT_NAMECHAR(100)PK
FK (T_)

Description
Trade identifier.

Transaction name, or description: e.g.
“Buy Keebler Cookies”, “Cash from saleof DuPont stock”.

CHARGEThe table contains information about charges for placing a trade request. Charges are based on thecustomer’s tier and the trade type.
Table Prefix: CH_
Column Name

Data TypeConstraints

CH_TT_ID

CHAR(3)

Not Null

CH_C_TIER

NUM(1)

Not Nullin 1,2,3

RelationsPK+
FK (TT_)
PK+

Description
Trade type identifier.
Customer’s tier.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 55 of 287

CH_CHRG

2.2.5.4

VALUE_T

Not Null>= 0

Charge for placing a trade request.

COMMISSION_RATE

The commission rate depends on several factors: the tier the customer is in, the type of trade, thequantity of securities traded, and the exchange that executes the trade.
Table Prefix: CR_
Column Name

Data TypeConstraints

CR_C_TIER

NUM(1)

CR_TT_ID

CHAR(3)

Not Null

CR_EX_ID

CHAR(6)

Not Null

CR_FROM_QTY

S_QTY_T

Not Nullin 1,2,3

Not Null>= 0

Relations

Description

PK+

Customer’s tier. Valid values 1, 2 or 3.

PK+

Trade Type identifier. Identifies the typeof trade.

FK (TT_)PK+
FK (EX_)PK+

Exchange identifier. Identifies theexchange the trade is against.
Lower bound of quantity being traded tomatch this commission rate.

Not Null

2.2.5.5

CR_TO_QTY

S_QTY_T

CR_RATENUM(5,2)>
CR_FROM_
QTY

Upper bound of quantity being traded tomatch this commission rate.

Not NullCommission rate. Ranges from 0.00 to
100.00. Example: 10% is 10.00.

>= 0

SETTLEMENT

The table contains information about how trades are settled: specifically whether the settlement is on
margin or in cash and when the settlement is due.
Table Prefix: SE_

2.2.5.6

Column Name

Data TypeConstraints

Relations

SE_T_ID

TRADE_T

Not Null

SE_CASH_TYPE

CHAR(40)

Not NullType of cash settlement involved:
possible values “Margin”, “CashAccount”.

SE_CASH_DUE_DATE

DATE

Not NullDate by which customer or brokeragemust receive the cash; date of trade plus
two days.

SE_AMT

VALUE_T

Not Null

Cash amount of settlement.

PK
FK (T_)

Description
Trade identifier.

TRADE

The table contains information about trades.
Table Prefix: T_
Column Name

Data TypeConstraints

Relations

Description

T_ID

TRADE_T

Not NullPK

Trade identifier.

T_DTS

DATETIME

Not NullDate and time of trade.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 56 of 287

T_ST_ID

CHAR(4)

Not Null

FK (ST_)

Status type identifier; identifies thestatus of this trade.

T_TT_ID

CHAR(3)

Not NullFK (TT_)

Trade type identifier; identifies the typeof his trade.

T_IS_CASH

BOOLEAN

T_S_SYMB

CHAR(15)

T_QTY

S_QTY_T

T_BID_PRICE

S_PRICE_T

T_CA_ID

IDENT_T

Not Null

T_EXEC_NAME

CHAR(49)

Not Null

T_TRADE_PRICE

S_PRICE_T

T_CHRGVALUE_T

T_COMM

VALUE_T

T_TAX

T_LIFO

2.2.5.7

VALUE_T

BOOLEAN

Not NullIs this trade a cash (1) or margin (0)trade?

in 0, 1
Not Null

FK (S_)

Not NullSecurity symbol of the security that wastraded.
Quantity of securities traded.

>0
Not Null

The requested unit price.

>0
FK (CA_)

Customer account identifier.
Name of the person executing the trade.
Unit price at which the security wastraded.

Not NullFee charged for placing this traderequest.

>= 0
Not NullCommission earned on this trade; may
be zero.

>= 0

Amount of tax due on this trade; can be
zero. Whether the tax is withheld fromthe settlement amount depends on thecustomer account tax status.

Not Null>= 0

If this trade is closing an existing position,is it executed against the newest-tooldest account holdings of this security(1=LIFO) or against the oldest-to-newest
account holdings (0=FIFO).

Not Null
in 0, 1TRADE_HISTORY

The table contains the history of each trade transaction through the various states.
Table Prefix: TH_
Column Name

2.2.5.8

Data TypeConstraints

TH_T_ID

TRADE_T

Not Null

TH_DTSDATETIME

Not Null

TH_ST_ID

CHAR(4)

Not Null

RelationsPK+
FK (T_)

Description
Trade identifier. This value will be used
for the corresponding T_ID in the
TRADE and SE_T_ID in the
SETTLEMENT table if this trade request
results in a trade.
Timestamp of when the trade history
was updated.

PK+
FK (ST_)

Status type identifier.

TRADE_REQUEST

The table contains information about pending limit trades that are waiting for a certain security pricebefore the trades are submitted to the market.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 57 of 287

Table Prefix: TR_

2.2.5.9

Column Name

Data TypeConstraints

TR_T_ID

TRADE_T

Not Null

TR_TT_ID

CHAR(3)

Not NullFK (TT_)

Trade request type identifier; identifies
the type of trade.

TR_S_SYMBCHAR(15)

Not Null

FK (S_)

Security symbol of the security thecustomer wants to trade.

TR_QTY

S_QTY_T

TR_BID_PRICE

S_PRICE_T

TR_B_ID

IDENT_T

Relations

Description

PK

Trade request identifier. This value will
be used for processing the pending limit
order when it is subsequently triggered.

FK (T_)

Not NullQuantity of security the customer had
requested to trade.

>0

Price the customer wants per unit of
security that they want to trade. Value ofzero implies the customer wants to trade
now at the market price

Not Null>0
Not Null

FK (B_)

Identifies the broker handling the trade.

TRADE_TYPE

The table contains a list of valid trade types.
Table Prefix: TT_
Column Name

Data TypeConstraints

Relations

Description

TT_ID

CHAR(3)

Not NullPK

Trade type identifier: Values are: “TMB”,“TMS”, “TSL”, “TLS”, and “TLB”.

TT_NAMECHAR(12)

Not Null

TT_IS_SELL

BOOLEAN

TT_IS_MRKTBOOLEAN

Trade type name. Examples “Limit
Buy", "Limit Sell", "Market Buy", "Market
Sell", “Stop Loss”.

Not Null

1 if this is a “Sell” type transaction. 0 if
this is a “Buy” type transaction.

in 0, 1

1 if this is a market transaction that is
submitted to the market exchange
emulator immediately. 0 if this is a limit
transaction.

Not Null
in 0, 1

The contents of the TRADE_TYPE table are shown below for readability, since the TT_ID values areused elsewhere in the specification.
TT_ID

TT_NAME

TT_IS_SELL

TT_IS_MRKTTLB

Limit-Buy

0

0

TLS

Limit-Sell

1

0

TMB

Market-Buy

0

1

TMS

Market-Sell

1

1

TSL

Stop-Loss

10

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 58 of 287

2.2.6

Market Tables
This group of tables contains information related to the exchanges, companies, and securities that create
the Market.

2.2.6.1

COMPANYThe table contains information about all companies with publicly traded securities.
Table Prefix: CO_

2.2.6.2

Column Name

Data TypeConstraints

Relations

Description

CO_ID

IDENT_T

Not NullPK

Company identifier.

CO_ST_ID

CHAR(4)

Not Null

FK (ST_)

Company status type identifier.
Identifies if this company is active ornot.

CO_NAMECHAR(60)

Not Null

CO_IN_ID

CHAR(2)

Not Null

CO_SP_RATE

CHAR(4)

Not NullCompany's credit rating from Standard& Poor.

CO_CEOCHAR(46)

Not NullName of Company's Chief Executive
Officer.

CO_AD_ID

IDENT_T

Not Null

CO_DESC

CHAR(150)

Not NullCompany description.

CO_OPEN_DATE

DATE

Not NullDate the company was founded.

Company name.
FK (IN_)FK (AD_)

Industry identifier of the industry thecompany is in.

Address identifier.

COMPANY_COMPETITORThis table contains information for the competitors of a given company and the industry in which thecompany competes.
Table Prefix: CP_
Column Name

Data TypeConstraints

CP_CO_ID

IDENT_T

Not Null

CP_COMP_CO_ID

IDENT_T

Not Null

CP_IN_ID

CHAR(2)

Not Null

RelationsPK+
FK (CO_)PK+
FK (CO_)PK+FK (IN_)

Description
Company identifier.
Company identifier of the competitor
company for the specified industry.
Industry identifier of the industry inwhich the CP_CO_ID company
considers that the CP_COMP_CO_ID
company competes with it. This may not
be either company’s primary industry.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 59 of 287

2.2.6.3

DAILY_MARKETThe table contains daily market statistics for each security, using the closing market data from the lastcompleted trading day. EGenLoader will load this table with data for each security for the period
starting 3 January 2000 and ending 31 December 2004.
Table Prefix: DM_

2.2.6.4

Column Name

Data TypeConstraints

Relations

Description

DM_DATEDATE

Not NullPK+

Date of last completed trading day.

DM_S_SYMBCHAR(15)

Not Null

DM_CLOSE

S_PRICE_T

Not NullClosing price for this security.

DM_HIGHS_PRICE_T

Not NullDay's High price for this security.

DM_LOW

S_PRICE_T

Not NullDay's Low price for this security.

DM_VOL

S_COUNT_T

Not NullDay's volume for this security.

PK+
FK (S_)

Security symbol of this security.

EXCHANGE

The table contains information about financial exchanges.
Table Prefix: EX_

2.2.6.5

Column Name

Data TypeConstraints

Relations

Description

EX_ID

CHAR(6)

Not NullPK

Exchange identifier. Values are, "NYSE","NASDAQ", "AMEX", ”PCX”.

EX_NAMECHAR(100)

Not NullExchange name.

EX_NUM_SYMB

NUM(6)

Not NullNumber of securities traded on thisexchange.

EX_OPENNUM(4)

Not NullExchange Daily start time expressed in
GMT.

EX_CLOSE

NUM(4)

Not NullExchange Daily stop time, expressed in
GMT.

EX_DESC

CHAR(150)

EX_AD_ID

IDENT_T

Description of the exchange.
Not NullFK (AD_)

Mailing address of exchange.

FINANCIAL

The table contains information about a company's quarterly financial reports. EGenLoader will load
this table with financial information for each company for the Quarters starting 1 January 2000 andending with the quarter that starts 1 October 2004.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 60 of 287

Table Prefix: FI_

2.2.6.6

Column Name

Data TypeConstraints

FI_CO_ID

IDENT_T

Not Null

FI_YEARNUM(4)

Not Null

FI_QTR

NUM(1)

FI_QTR_START_DATE

DATE

Not NullStart date of quarter.

FI_REVENUEFIN_AGG_T

Not NullReported revenue for the quarter.

FI_NET_EARN

FIN_AGG_T

Not Null

Net earnings reported for the quarter.

FI_BASIC_EPSVALUE_T

Not NullBasic earnings per share reported forthe quarter.

FI_DILUT_EPS

VALUE_T

Not NullDiluted earnings per share reported
for the quarter.

FI_MARGIN

VALUE_T

Not NullProfit divided by revenues for thequarter.

FI_INVENTORYFIN_AGG_T

Not NullValue of inventory on hand at the endof the quarter.

FI_ASSETS

FIN_AGG_T

Not NullValue of total assets at the end of thequarter.

FI_LIABILITYFIN_AGG_T

Not NullValue of total liabilities at the end of
the quarter.

FI_OUT_BASIC

S_COUNT_T

Not NullAverage number of common shares
outstanding (basic).

FI_OUT_DILUT

S_COUNT_T

Not NullAverage number of common shares
outstanding (diluted).

Not Nullin 1,2,3,4

RelationsPK+
FK (CO_)

Description
Company identifier.

PK+

Year of the quarter end.

PK+

Quarter number that the financial
information is for: valid values 1, 2, 3,
4.

INDUSTRY

The table contains information about industries. Used to categorize which industries a company is in.
Table Prefix: IN_

2.2.6.7

Column Name

Data TypeConstraints

Relations

Description

IN_ID

CHAR(2)

Not NullPK

Industry identifier.

IN_NAMECHAR(50)

Not Null

IN_SC_ID

CHAR(2)

Not NullIndustry name. Examples: "Air Travel","Air Cargo", "Software", "Consumer
Banking", "Merchant Banking", etc.
FK (SC_)

Sector identifier of the sector theindustry is in.

LAST_TRADE

The table contains one row for each security with the latest trade price and volume for each security.
Table Prefix: LT_
Column Name

Data TypeConstraints

Relations

Description

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 61 of 287

2.2.6.8

PK

LT_S_SYMBCHAR(15)

Not Null

LT_DTSDATETIME

Not NullDate and timestamp of when this row
was last updated.

LT_PRICE

S_PRICE_T

Not NullLatest trade price for this security.

LT_OPEN_PRICE

S_PRICE_T

Not NullPrice the security opened at today.

LT_VOL

S_COUNT_T

Not NullVolume of trading on the market for thissecurity so far today. Value initialized to0.

FK (S_)

Security symbol.

NEWS_ITEM

The table contains information about news items of interest.
Table Prefix: NI_

2.2.6.9

Column Name

Data TypeConstraints

Relations

Description

NI_ID

IDENT_T

Not Null

PK

News item identifier.

NI_HEADLINE

CHAR(80)

Not NullNews item headline.

NI_SUMMARY

CHAR(255)

Not NullNews item summary.

NI_ITEMBLOB(100000)
or BLOB_REF

Not NullLarge object containing the news item orlinks to the story.

NI_DTSDATETIME

Not NullDate and time the news item was
published.

NI_SOURCE

CHAR(30)

Not Null

Source of the news item.

NI_AUTHOR

CHAR(30)

Author of the news item. May be null if
the news item came off a wire service.

NEWS_XREF

The table contains a cross-reference of news items to companies that are mentioned in the news item.
Table Prefix: NX_

2.2.6.10

Column Name

Data TypeConstraints

NX_NI_ID

IDENT_T

Not Null

NX_CO_ID

IDENT_T

Not Null

RelationsPK+
FK (NI_)PK+
FK (CO_)

Description
News item identifier.
Company identifier of the company (orone of the companies) mentioned in thenews item.

SECTOR

The table contains information about market sectors.
Table Prefix: SC_
Column Name

Data TypeConstraints

Relations

Description

SC_ID

CHAR(2)

Not NullPK

Sector identifier.

SC_NAMECHAR(30)

Not NullSector name. Examples: “Energy”,“Materials”, “Industrials”, “Health Care,etc.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 62 of 287

2.2.6.11

SECURITY

This table contains information about each security traded on any of the exchanges.
Table Prefix: S_

2.2.7

Column Name

Data TypeConstraints

Relations

Description

S_SYMB

CHAR(15)

Not NullPK

Security symbol used to identify the
security on "ticker".

S_ISSUE

CHAR(6)

Not Null

S_ST_ID

CHAR(4)

Not Null

S_NAME

CHAR(70)

Not Null

S_EX_ID

CHAR(6)

Not NullFK (EX_)

Exchange identifier of the exchange
the security is traded on.

S_CO_ID

IDENT_T

Not NullFK (CO_)

Company identifier of the company
this security is issued by.

S_NUM_OUT

S_COUNT_T

Not NullNumber of shares outstanding for thissecurity.

S_START_DATE

DATE

Not NullDate security first started trading.

S_EXCH_DATE

DATE

Not NullDate security first started trading on
this exchange.

S_PE

VALUE_T

Not NullCurrent share price to earnings per
share ratio.

S_52WK_HIGH

S_PRICE_T

Not NullSecurity share price 52-week high.

S_52WK_HIGH_DATE

DATE

Not NullDate of security share price 52-weekhigh.

S_52WK_LOW

S_PRICE_T

Not NullSecurity share price 52-week low.

S_52WK_LOW_DATE

DATE

Not NullDate of security share price 52-weeklow.

S_DIVIDENDVALUE_T

Not NullAnnual Dividend per share amount.
May be zero, is not allowed to be
negative.

S_YIELDNUM(5,2)

Not NullDividend to share price ratio. Value isin percent. Example 10.00 is 10%

Security issue type. Example:"COMMON", "PERF_A", "PERF_B",
etc.
FK (ST_)

Security status type identifier.
Identifies if this security is active ornot.
Security name.

Dimension Tables
This group of tables includes 4 dimension tables that contain common information such as addresses
and zip codes.

2.2.7.1

ADDRESS

This table contains address information.
Table Prefix: AD_
Column Name

Data TypeConstraints

Relations

Description

AD_ID

IDENT_T

Not NullPK

Address identifier.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 63 of 287

2.2.7.2

AD_LINE1

CHAR(80)

Address Line 1.

AD_LINE2

CHAR(80)

Address Line 2.

AD_ZC_CODE

CHAR(12)

AD_CTRY

CHAR(80)

Not NullFK (ZC_)

Zip or postal code.
Country.

STATUS_TYPE

This table contains all status values for several different status usages. Multiple tables reference thistable to obtain their status values.
Table Prefix: ST_
Column Name

Data TypeConstraints

Relations

Description

ST_ID

CHAR(4)

Not NullPK

Status type identifier.

ST_NAMECHAR(10)

Not NullStatus value. Examples: "Active","Completed", "Pending", “Canceled” and"Submitted”.

The contents of the STATUS_TYPE table are shown below for readability, since the ST_ID values areused elsewhere in the specification.

2.2.7.3

ST_ID

ST_NAME

ACTV

ActiveCMPT

Completed

CNCL

Canceled

PNDG

Pending

SBMT

Submitted

TAXRATE

The table contains information about tax rates.
Table Prefix: TX_

2.2.7.4

Column Name

Data TypeConstraints

Relations

Description

TX_ID

CHAR(4)

Not NullPK

Tax rate identifier. Format - two letters
followed by one digit. Examples: ‘US1’,‘CA1’.

TX_NAMECHAR(50)

Not NullTax rate name.

TX_RATENUM(6,5)

Not NullTax rate, between 0.00000 and 1.00000,
inclusive.

>= 0

ZIP_CODEThe table contains zip and postal codes, towns, and divisions that go with them.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 64 of 287

Table Prefix: ZC_
Column Name

Data TypeConstraints

Relations

Description

ZC_CODE

CHAR(12)

Not NullPK

Postal code.

ZC_TOWN

CHAR(80)

Not Null

Town.

ZC_DIV

CHAR(80)

Not NullState or province or county.

2.3

Implementation Rules

2.3.1

The physical clustering of records within the database is allowed.

2.3.2

All TPC-E required tables must have the properly scaled number of rows as defined by the database
population requirements in Clause 2.6.

2.3.3

Table Partitioning

2.3.3.1

Horizontal partitioning of tables is allowed. Groups of rows from a table may be assigned to different
files, disks, or areas. If implemented, the details of such partitioning must be reported in the Report.

2.3.3.2

Vertical partitioning of tables is allowed. Groups of columns of one table may be assigned to files,
disks, or areas different from those storing the other columns of that table. If implemented, the detailsof such partitioning must be reported in the Report (see Clause 2.5 for limitations).

2.3.3.3

Assignment of data to different files, disks, or areas, not based on knowledge of the logical structure of
the data (e.g., knowledge of row or column boundaries), is not considered partitioning. For example,
distribution or striping over multiple disks of a physical file which stores one or more logical tables is
not considered partitioning as long as this distribution is done by the hardware or software without
knowledge of the logical structure stored in the physical file.

2.3.4

Replication is allowed for all tables. All copies of TPC-E tables that are replicated must meet all
requirements for atomicity, consistency, and isolation as defined in Clauses 7.2, 7.3 and 7.4. If
implemented, the details of such replication must be reported in the Report.
Comment: Only one copy of a replicated TPC-E table needs to meet the Durability requirements definedin Clause 7.5.
2.3.5

Columns may be added and/or duplicated from one TPC-E table to another as long as these changes
do not improve performance.

2.3.6

Each TPC-E column, as described by the table definitions in Clause 2.2, must be logically discrete andindependently accessible by the DBMS. For example, ADDRESS.AD_LINE1 andADDRESS.AD_LINE2 are not allowed to be implemented as two sub-parts of a single column
ADDRESS.AD_LINE.

2.3.7

Each TPC-E column, as described by the table definitions in Clause 2.2, must be accessible by the
DBMS as a single column. For example, NEWS_ITEMS.NI_ITEM is not allowed to be implemented as
two separate columns NEWS_ITEMS.NI_ITEM1 and NEWS_ITEMS.NI_ITEM2.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 65 of 287

2.3.8The Primary Key of each table must not directly represent the physical disk addresses of the row or any
offsets thereof. The Application is not allowed to reference rows using relative addressing since they
are simply offsets from the beginning of the storage space. This does not preclude hashing schemes orother file organizations that have provisions for adding, deleting, and modifying records in theordinary course of processing.
Comment 1: It is the intent of this clause that the Application Program (see Clause 1.2) executing thetransaction, or submitting the transaction request, not use physical identifiers, but logical identifiers for
all accesses, and contain no user written code which translates or aids in the translation of a logical key
to the location within the table of the associated row or rows. For example, it is not legitimate for the
Application to build a "translation table" of logical-to-physical addresses and use it to enhance
performance.
Comment 2: Internal record or row identifiers, for example, Tuple IDs or cursors, may be used under thefollowing condition. For each transaction executed, initial access to any row must be via the column(s)specified in the transaction Profile and no other columns. Initial access includes insertion, deletion,
retrieval, and update of any row.
2.3.9

While inserts and deletes are not performed on all tables, the system must not be configured to takespecial advantage of this fact during the test. Although inserts are inherently limited by the storage
space available on the configured system, there must be no restriction on inserting in any of the nonGrowing Tables a minimum number of rows equal to 5% of the table cardinality.
Comment: It is required that the space for the additional 5% table cardinality (and corresponding growthin associated User-Defined Objects, such as indices) be configured for the Test Run and priced (asFixed Space per Clause 6.6.6.3) accordingly. For systems where space is configured and dynamicallyallocated at a later time, this space must be considered as allocated and included as Fixed Space when
priced.
2.3.10The implementation of the BLOB object must satisfy the following properties:


Changes to the data in the object must be under the same transactional control as the changes to theobjects of any other type.



Recovery after Catastrophic failure must be capable of restoring all objects, including BLOBs, to thesame point in time.

The object, and any associated references to it, must be treated as a unit with respect to atomicity.

Comment: The implementation of BLOB in the NEWS_ITEM table may be implemented either byspecific inclusion of the BLOB in the table or by use of a reference to a BLOB object stored elsewhere on
the System Under Test.
2.3.11

User-Defined Objects
Any object defined in the database is considered a User-Defined Object, except for the following:

2.3.11.1

a TPC-E Table (see clause 2.2.3)



a required Primary Key (see clause 2.2.3.1)



a required Foreign Key (see clause 2.2.3.2)



a required constraint (see clause 2.2.3.3)

Database Metadata

There are no restrictions on User-Defined Objects, provided that: all Transaction and Frame implementation rules from clause 3.2 are met
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 66 of 287

 all ACID requirements in clause 7 are met

2.4

Integrity Rules

2.4.1

In any Committed state, the Primary Key values must be unique within each table. For example, in thecase of a horizontally partitioned table, Primary Key values of rows across all partitions must be
unique.

2.4.2

In any Committed state, no ill-formed rows may exist in the database. An ill-formed row occurs whenthe value of any column cannot be determined. For example, in the case of a vertically partitioned
table, a row must exist in all the partitions.

2.4.3

Referential Integrity (RI) must be enforced by the database for all Foreign Key (FK) and Primary Key(PK) relations defined between TPC-E tables.
Comment: Referential Integrity preserves the relationship of data between tables, by restricting actions

performed on Primary Keys and Foreign Keys in a table. Referential Integrity prevents removing
rows containing Primary Keys that are referenced by Foreign Keys in other tables in the database
without also removing the rows with corresponding/referencing Foreign Keys. Referential Integrity
also prevents adding rows containing Foreign Keys that refer to Primary Keys whose rows are notalready present in the database. Referential Integrity does not allow modifications to Primary Key
columns of rows that are referenced by Foreign Keys in other tables in the database without also
modifying the corresponding/referencing Foreign Keys to be equal to the new Primary Key.

2.5

Data Access Transparency Requirements
Data Access Transparency is the property of the system that removes from the Application Program
any knowledge of the location and access mechanisms of partitioned data. An implementation thatuses vertical and/or horizontal partitioning must meet the requirements for transparent data accessdescribed here.
No finite series of tests can prove that the system supports complete data access transparency. The
requirements below describe the minimum capabilities needed to establish that the system provides
transparent data access.
Comment: The intent of this clause is to require that access to physically and/or logically partitioned

data be provided directly and transparently by services implemented by commercially available layers
below the Application Program such as the data/file manager (DBMS), the Operating System, thehardware, or any combination of these.
2.5.1

Each of the tables described in Clause 2.2 (and any additional tables used in the implementation of theTransactions) must be identifiable by names that have no relationship to the partitioning of tables. Alldata manipulation operations in the Application Program (see Clause 1.2) must use only these names.

2.5.2

The system must prevent any data manipulation operation performed using the names described in
Clause 2.5.1 that would result in a violation of the integrity rules (see Clause 2.4). For example: thesystem must prevent a non-TPC-E application from committing the insertion of a row in a verticallypartitioned table unless all partitions of that row have been inserted.

2.5.3

Using the names which satisfy Clause 2.5.1, any arbitrary non-TPC-E application must be able tomanipulate any set of rows or columns:

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 67 of 287



Identifiable by any arbitrary condition supported by the underlying DBMS

Using the names described in Clause 2.5.1 and using the same data manipulation semantics andsyntax for all tables.

For example, the semantics and syntax used to update an arbitrary set of rows in any one table mustalso be usable when updating another arbitrary set of rows in any other table.
Comment: The intent is that the TPC-E Application Program uses general-purpose mechanisms tomanipulate data in the database.

2.6

TPC-E Database Size and Table Cardinality
The transaction load generated to service customer accounts and to interact with financial markets
drives the throughput of the TPC-E benchmark. To increase the throughput, more customers and theirassociated data must be configured. The cardinality of the CUSTOMER table is the basis of the TPC-E
database size and scaling. CUSTOMER table cardinality is determined based on the transaction
throughput metric requirements defined in Clause 6.6.7.
Configured Customers means the number of customers (with corresponding rows in the associated
TPC-E tables) configured at database generation.
The TPC-E benchmark has three types of sizing requirements for its tables:Fixed Tables: These tables always have the same number of rows regardless of the database size
and transaction throughput. For example, TRADE_TYPE has five rows.



Scaling Tables: These tables each have a defined cardinality that has a constant relationship to thecardinality of the CUSTOMER table. Transactions may update rows from these tables, but the table
sizes remain constant.

Growing Tables: These tables each have an initial cardinality that has a defined relationship to thecardinality of the CUSTOMER table. However, the cardinality increases with new growth during
the benchmark run at a rate that is proportional to transaction throughput rates.

Comment: The HOLDING and HOLDING_SUMMARY tables are considered Growing Tables. Rows

are added and deleted from the HOLDING and HOLDING_SUMMARY tables during the benchmark
execution, but the average size of the tables continues to grow at an insignificant rate during SteadyState. The TRADE_REQUEST table is also considered a Growing Table, even though its average size
is a fixed relationship to the transaction throughput rates and not to the cardinality of the CUSTOMER
table.
2.6.1

Initial Database Size Requirements

2.6.1.1

The test database must be initially populated using data generated by EGenLoader. By definition, the
TPC provided EGenLoader produces the correct number of rows for each table. The test database must
be built including the initial database population and User-Defined Objects present immediately prior
to the first Test Run.

2.6.1.2

The initial database population is based on the number of customers. The benchmark Sponsor selects
the CUSTOMER table cardinality, based on the desired transaction throughput. Clause 6.6.8.2 defines
the Nominal Throughput for a given number of rows in the CUSTOMER table. The minimum numberof rows for the CUSTOMER table is 5000. The size of the CUSTOMER table can be increased inincrements of 1000 customers. A set of 1000 customers is known as a Load Unit.

2.6.1.3

The Growing Tables are populated with an initial set of rows sufficient to enable all benchmark
Transactions to run.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 68 of 287

2.6.1.4

The Scale Factor is the number of required customer rows per single Transactions-Per-Second-E(tpsE). The Scale Factor for Nominal Throughput is 500.

2.6.1.5

The Initial Trade Days (ITD) is the number of Business Days used to populate the database. This
population is made of trade data that would be generated by the SUT when running at the Nominal
Throughput for the specified number of Business Days. The number of Initial Trade Days is 300.

2.6.1.6

The number of Load Units configured must be equal to the number of Load Units actually accessed
during the Test Run.

2.6.1.7

The following variables are used as an aid in defining TPC-E table cardinalities:
Variable

Table

Description

customers

CUSTOMER

Number of rows in the CUSTOMER table.

accounts

CUSTOMER_ACCOUNT

Number of rows in the CUSTOMER_ACCOUNT table. Equal to 5 *customers.

tradesTRADE

settledSETTLEMENT

Number of trade rows in the TRADE table. The trades number isequal to 17280 * customers (300 days of initial population at SF =500).

Number of rows in the COMPANY table. 500 companies per Load
Unit of 1000 customers.

companies COMPANY
securities

2.6.1.8

Number of settled trade rows in the SETTLEMENT table. The settled
number is equal to trades.

Number of rows in the SECURITY table. 685 securities per Load Unitof 1000 customers.

SECURITY

The following rules are used by EGenLoader to calculate the cardinalities of the Scaling Tables andGrowing Tables. The EGen package uses random number generators to set the number of rows for
relationships such as securities per account and, as a result, the cardinality of some TPC-E tables canonly be approximated.
Table

Variable Used

Rule

ACCOUNT_PERMISSION

accounts

60% have just the customer as the executor
38% have the customer and 1 other executor
2% have the customer and 2 other executors
Avg. is ~1.42 * accounts

ADDRESScustomerscompanies + EXCHANGE(4) + customers

BROKER

customers

0.01 * customers (or 1 broker per 100 customers)

CASH_TRANSACTION

settled~0.92 * settled (84% of buys and 100% of sells are cash)

COMPANYcustomers

500 * (customers/1000)

COMPANY_COMPETITOR

companies

3 * companies

CUSTOMER_ACCOUNT

customers

5 * customers

CUSTOMER_TAXRATE

customers

2 * customers

DAILY_MARKET

securities

securities * 1,305 (5 years of 5-day work weeks with

FINANCIAL

companies

companies * 20 quarters (5 years)

HOLDINGsettled~0.051 * settled (assumes ITD = 300 and SF = 500)

two leap years)

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 69 of 287

HOLDING_HISTORY

settled~1.340 * settled (assumes ITD = 300 and SF = 500)

HOLDING_SUMMARY

accounts~9.956 * accounts (assumes ITD = 300 and SF = 500)

LAST_TRADE

securities

1 * securities

NEWS_ITEM

companies

2 * companies

NEWS_XREF

companies

2 * companies

SECURITY

customers

685 * (customers/1000)

SETTLEMENT

settled

1 * settled

TRADE

customers

TRADE_HISTORY

17280 * customers = ((ITD * 8 * 3600) / SF) *customers~((2 rows per market trade) * 0.6)+((3 rows per limit trade) * 0.4)
Average is (2.4 * settled)

settledTRADE_REQUEST

2.6.1.9

0

WATCH_LIST

customers

Each customer has one watch list (1 * customers)

WATCH_ITEM

customers

Average=100 items per watch list * customers

The following list contains the cardinality of Fixed Tables.
Fixed Tables

Cardinality

CHARGE15

5 trade types * 3 customer tiers

COMMISSION_RATE

240

4 rates * 4 exchanges * 5 trade types * 3 customer tiers

EXCHANGE

44 exchanges

INDUSTRY

102

102 industries

SECTOR

12

12 sectors

STATUS_TYPE

55 status types

320

320 tax rates

5

5 trade types

TAXRATETRADE_TYPE
ZIP_CODE

2.6.1.10

Cardinality Formula

14,741

14,741 zip codes

The following list contains the cardinality of the Scaling Tables.
Scaling Tables

Cardinality

Cardinality Formula

CUSTOMER

5,000

Scaled based on transaction rate

CUSTOMER_TAXRATE

10,000

customers * 2

CUSTOMER_ACCOUNT

25,000accounts = (5 * customers)

ACCOUNT_PERMISSION~35,500

accounts * (Average of ~1.42 permissions per account)

ADDRESS

7,504

BROKER

50

COMPANY

2,500

companies + EXCHANGE (4) + customers
customers * 0.01
500 * (customers/1000)

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 70 of 287

COMPANY_COMPETITORDAILY_MARKET

2.6.1.11

7,500

companies * 3

4,469,625

securities * 1,305

FINANCIAL

50,000companies * 20

LAST_TRADE

3,425

securities * 1

NEWS_ITEM

5,000

companies * 2

NEWS_XREF

5,000

companies * 2

SECURITY

3,425

685 * (customers/1000)

WATCH_LIST

5,000

customers * 1

WATCH_ITEM~ 500,000

customers * (Average of ~100 securities per watch list)

The following list shows the initial cardinality of the Growing Tables.
Growing Tables

Cardinality

Cardinality Formula

CASH_TRANSACTION~79,488,000~0.92 * settled (84% of buys & 100% of sells are cash)

HOLDING~4,406,400~0.051 * settled (assumes ITD = 300 and SF = 500)

~115,776,000~1.340 * settled (assumes ITD = 300 and SF = 500)

HOLDING_HISTORYHOLDING_SUMMARY~248,900~9.956 * accounts

SETTLEMENT

86,400,000

1 * settled

TRADE

86,400,000((ITD * 8hr/day * 3600sec/hr * customers) /SF)

TRADE_HISTORY~207,360,000

TRADE_REQUEST

0~(2.4 * trades)
0

2.6.2

Test Run Database Size Requirements

2.6.2.1

The following list shows the increase in rows per second for the Growing Tables (except for
TRADE_REQUEST) during a Test Run. The rate of growth may decline after running for a large
number of days.
Table Name

Cardinality Formula

CASH_TRANSACTION~0.92 * (customers/SF)

HOLDING~0.044 * (customers/SF)

HOLDING_HISTORY~1.343 * (customers/SF)

SETTLEMENT

1 * (customers/SF)

TRADE

1 * (customers/SF)

TRADE_HISTORY~2.4 * (customers/SF)

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 71 of 287

The TRADE_REQUEST table is empty at the start of a Test Run and does grow at first during runtime,
but it soon reaches a cardinality that is dependent on recent performance and not on the length of the
Test Run. The approximate cardinality of TRADE_REQUEST during the Steady State portion of a Test
Run can be estimated as ~60 rows * Measured Throughput (see Clause 6.6.8.4). Considerable variationin this cardinality is possible both while running and at the end of a Test Run.
2.6.2.2

The test database must be built to sustain the Reported Throughput during a Business Day. Thismeans that test database must have a Business Day’s worth of additional space for data, index and log
online. This excludes performing on the database any operation that does not occur during the
Measurement Interval.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 72 of 287

CLAUSE 3 -- TRANSACTIONS
3.1

Introduction
The core of each TPC-E Transaction runs on the Database Server, but the logic of the Transaction
interacts with several components of the benchmark environment. This section defines all aspects of
the Transactions, including side effects on other components of the benchmark environment.

3.1.1

Definitions

3.1.1.1

A Transaction is composed of EGenTxnHarness and of the invocation of one or more Frames. The
Trade-Cleanup Transaction is an exception. Sponsors may but do not have to run the Trade-Cleanup
Transaction from EGenTxnHarness.

3.1.1.2

The EGenTxnHarness is the TPC provided transaction logic, which the Sponsor is not allowed to alter.
The EGenTxnHarness is implemented in a manner that precludes the consolidation of multiple Frames
within a Transaction.

3.1.1.3

A Frame is the Sponsor implemented Transaction logic, which is invoked as a unit of execution by the
EGenTxnHarness. The database interactions of a Transaction are all initiated from within its Frames.
LegendTPC Provided
Sponsor Provided
Commercial Product

EGenTxnHarness
Input from Driver

TPC-E Transaction

TPC-E Logic
Frame Call
Frame 1
Frame Return
TPC-E Logic
DBMS
TPC-E Logic
Frame Call
Frame N

Output to Driver

Frame Return
TPC-E Logic

Figure 3.a - Frames Interfacing with the Harness and the Database
3.1.1.4

A Database Transaction is an ACID unit of work.

3.1.2

Database Footprint Definition
This Clause describes the format used to specify the Database Footprint of each Transaction in thisbenchmark.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 73 of 287

3.1.2.1

The Database Footprint of a Transaction is the set of required database interactions to be executed bythat Transaction.

3.1.2.2

Each Database Footprint is presented in a tabular format where the columns specify the following:

The first column denotes either one of the database tables defined in Clause 2.2 or the words“Transaction Control” that denotes the entire Transaction. The last row defines the overall
Transaction.



The second column denotes one of the following:

3.1.2.3oA specific column name of a database table as defined in Clause 2.2.

oThe string “# rows” that specifies the exact number of rows containing all columns of adatabase table. For example, “2 rows” indicates two complete rows of a database table.

o

The string “Row(s)” that specifies a variable number of rows containing all columns of adatabase table.

The remaining columns correspond with each of the Frames of the Transaction and contain the
database interactions or Transaction control operations required to be executed in that Frame.

The following table is an example of the Database Footprint of a Transaction.
Example Database Footprint
Frame
Table

Column1

CUSTOMER_ACCOUNTHOLDINGTRADE_HISTORY

CA_BAL

Reference

CA_C_ID

ReturnCA_TAX_ST

Return2*

H_PRICE

ReturnH_QTY

ModifyRow(s)

Remove *

1 row

Add *

1 row

Transaction Control

3*

Add
Start

Rollback *Commit

For the last row of the Database Footprint where the words “Transaction Control” appears, eachcolumn corresponds to one of the transaction Frames. The content of the columns denote which
Transaction control operations occur in that Frame. The possible Transaction control operations are as
follows:
The word “Start” indicates that the specified Frame contains a control operation that starts a
Database Transaction. The start of a Database Transaction can only occur in a Frame where
the word “Start” is specified.



The word “Rollback” indicates that the specified Frame contains a control operation that rolls
back the Database Transaction. The explicit rolling back of a Database Transaction can only
occur in a Frame where the word “Rollback” is specified.

The word “Commit” indicates that the specified Frame contains a control operation that commits a
Database Transaction.
Commit: a control operation that:
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 74 of 287



Is initiated by a unit of work (a Transaction)

Is implemented by the DBMS

Signifies that the unit of work has completed successfully and all tentatively modified data areto persist (until modified by some other operation or unit of work)

Upon successful completion of this control operation both the Transaction and the data are said to be
Committed.Commit: a control operation that:

Is initiated by a unit of work (a Transaction)

Is implemented by the DBMS

Signifies that the unit of work has completed successfully and all tentatively modified data areto persist (until modified by some other operation or unit of work)

Upon successful completion of this control operation both the Transaction and the data are said to
be Committed.
The explicit committing of a Database Transaction can only occur in a Frame where the word
“Commit” is specified.
Multiple Transaction control operations may occur within the same Frame. For
example, a Transaction that consists of a single Frame would have both “Start” and “Commit” inits Database Footprint column corresponding with Frame 1.
Comment:

For remaining rows of the Database Footprint the column corresponding to each Frame contains theaccess method required for the table column listed in that row. The possible access methods are as
follows:
The word “Reference” indicates that the TPC-E table column is identified in the database andthe content is accessed within the Frame without passing the content of the table column to the
EGenTxnHarness.

The word “Return” indicates that the TPC-E table column is referenced and that its content isretrieved from the database and passed to the EGenTxnHarness. The table column must be
referenced in the same Frame where the word “Return” is specified. The content of the table
column can only be passed to subsequent Frames via the input and output parametersspecified in the Frame parameters.



The word “Modify” indicates that the content of a TPC-E table column is modified within the
Frame. The content of the table column can only be changed in a Frame where the word
“Modify” is specified. When the original content of the table column must also be referenced
or returned before it is modified, a “Reference” or a “Return” access method is also specified.



The word “Add” indicates that a number of rows are added to the TPC-E table specified by the
Database Footprint. TPC-E Table row(s) can only be added in a Frame where the word “Add”
is specified. The number of rows that are added is specified in the second column of the
Database Footprint with either “# row” for a fixed number of rows or “row(s)” for anunspecified number of rows.

The word “Remove” indicates that a number of rows are removed from the TPC-E tablespecified by the Database Footprint. Table row(s) can only be removed in a Frame where theword “Remove” is specified. The number of rows that are removed is specified in the second
column of the Database Footprint with either “# row” for a fixed number of rows or “row(s)”for an unspecified number of rows.

An asterisk following any item in the column of a given Frame denotes that thetransaction control, the database interactions, or the execution of the entire Frame is conditional.
The EGenTxnHarness defines under which conditions the Frame will be executed.
Comment 1:

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 75 of 287

In the example Database Footprint above, the Database Transaction is started in
Frame 1. If Frame 2 is executed the Database Transaction may be rolled back. If Frame 3 is
executed the Database Transaction must be Committed. For the table CUSTOMER_ACCOUNT,
the table column CA_BAL is referenced and the table columns CA_C_ID and CA_TAX_ST are
returned in Frame 1. For the HOLDING table, the column H_PRICE is returned and H_QTY is
modified if Frame 2 is executed. Additionally, if Frame 2 is executed, a number of rows areconditionally removed from the HOLDING table and 1 row is conditionally added to the
HOLDING table. For the TRADE_HISTORY table, a row is added if Frame 3 is executed.
Comment 2:

Comment 3: The programming semantics used to implement the required access methods for a given

table column is not restricted from performing operations typically associated with a different
access method, as long as the implementation of the Frame is functionally equivalent to thespecified Pseudo-code. For example, “select for update” and “select with UPDLOCK” arecompliant implementations of a Reference access method.

3.2

Transaction Implementation Rules

3.2.1

Frame Implementation

3.2.1.1

The implementation of a Frame is not allowed to assume any prior knowledge of EGen’s data
generation methods or values for data elements defined in the database schema for the benchmark,except for the EGen constants listed in the table below.
Comment 1: The intent of this clause is to prevent the Frames from using constant values, or othermeans, to circumvent database references to static or infrequently changing data elements. In general,
using any private knowledge specific to the benchmark, but which is not explicitly furnished to theTransaction or the Frame, via Transaction inputs or Transaction Pseudo-code, is prohibited.
3.2.1.2

The following table shows EGen constants used as limits when generating the number of values forTransaction inputs or when accepting Transaction outputs. These constant limits are provided in thespecification for explicit usage in the corresponding Clause 3.3 Frame Implementations.
Description

Constant

Value EGen Filename

Broker-Volume
Minimum number of input broker names

min_broker_list_len

20

TxnHarnessStructs.h

Maximum number of input broker names

max_broker_list_len

40

TxnHarnessStructs.h

Maximum customer accounts per customer

max_acct_len

10

TxnHarnessStructs.h

Maximum number of TRADE_HISTORY rows
to returnmax_hist_len

30

TxnHarnessStructs.h

max_feed_len

20

TxnHarnessStructs.h

Minimum number of DAILY_MARKET rows
to return

min_day_len

5

TxnHarnessStructs.h

Maximum number of DAILY_MARKET rows
to return

max_day_len

20

TxnHarnessStructs.h

Maximum number of FINANCIAL rows toreturnmax_fin_len

20

TxnHarnessStructs.h

Maximum number of NEWS_ITEM rows to

max_news_len

2

TxnHarnessStructs.h

Customer-Position

Market-Feed
Maximum number of items on the ticker

Security-Detail

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 76 of 287

return
Maximum number of
COMPANY_COMPETITOR rows to return

max_comp_len

3

TxnHarnessStructs.h

Maximum number of TRADE rows to returnfor Transaction

TradeLookupMaxRows

20

MiscConsts.h

Maximum number of TRADE rows to returnfor Frame 1

TradeLookupFrame1MaxRows

20

MiscConsts.h

Maximum number of TRADE rows to returnfor Frame 2

TradeLookupFrame2MaxRows

20

Maximum number of TRADE rows to returnfor Frame 3

TradeLookupFrame3MaxRows

20

TradeLookupMaxTradeHistoryRowsReturned3

max_trade_status_len

50

TxnHarnessStructs.h

Maximum number of TRADE rows to returnfor Transaction

TradeUpdateMaxRows

20

MiscConsts.h

Maximum number of TRADE rows to returnfor Frame 1

TradeUpdateFrame1MaxRows

20

MiscConsts.h

Maximum number of TRADE rows to returnfor Frame 2

TradeUpdateFrame2MaxRows

20

Maximum number of TRADE rows to returnfor Frame 3

TradeUpdateFrame3MaxRows

20

TradeUpdateMaxTradeHistoryRowsReturned

3

Trade-Lookup

Maximum number of TRADE _HISTORY
rows to return

MiscConsts.h
MiscConsts.h
MiscConsts.h

Trade-Status
Maximum number of trade status rows toreturnTrade-Update

Maximum number of TRADE _HISTORY
rows to return3.2.1.3

MiscConsts.h
MiscConsts.h
MiscConsts.h

All data exchanges between Frames must be done by the EGenTxnHarness through its use of input
and output parameters passed in and out of the Frames.
Comment 1: The intent of this clause is to prevent the Frames from using global variables, or othermeans, for storing and retrieving information across multiple invocations of the same or different
Frames in order to avoid work intended to be done during each individual invocation.
Comment 2: The Test Sponsor may augment each Frame with code to unpack the input parameters

received from the EGenTxnHarness and to pack the output parameters returned to the
EGenTxnHarness.
3.2.1.4

The Frame Implementation must perform each database interaction specified in the Transaction’s
Database Footprint, using the specified access method.

3.2.1.5

The Frame Implementation must access any column that is marked as Reference. It is also free toaccess other columns that are not marked as Reference. For the other database interactions, the Frame
Implementation must perform all the required operations and/or return all the specified column
values.

3.2.1.6

The implementation of each Frame must be functionally equivalent to the Pseudo-code provided forthat Frame in Clause 3.3. Functional equivalence is satisfied when:
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 77 of 287



For a given set of inputs the implementation produces the same outputs and causes the samechange in database state as the Pseudo-code. A change in database state is a change to a TPC-E
Table or TPC-E Table column, resulting from any Modify, Add or Remove access method
defined by the Transaction’s Database Footprint.

All access methods in the Database Footprint are performed.

No additional Add/Modify/Remove access methods against any TPC-E Table are performed.

Comment: Additional Reference access methods against any TPC-E Table may be performed.

Additional access methods against any User-Defined Object may be performed.
3.2.1.7

The minimum decimal precision for any computation performed as part of the Frame must be themaximum decimal precision of all the individual items in that calculation.

3.2.1.8

Each Frame and Transaction has a status output parameter used to indicate the execution status of the
Frame or Transaction. A status value of 0 indicates success. A negative status value indicates an errorthat would invalidate a Test Run. A positive non-zero integer value for status indicates a warning.
Warnings mean that an unexpected result was generated and the Test Sponsor and Auditor should
investigate the unexpected result. The unexpected result may be due to a rare but legal condition or it
may be because of an incorrect implementation or run-time problem. If the latter is the cause of thewarning, it must be treated as an error that invalidates the Test Run.
The following table shows the positive warning numbers and where they may happen in EGen.

3.2.1.9

Transaction

Frame

Warning
StatusReason for Warning

Trade-Lookup

2

+621

num_found == 0

Trade-Lookup

3

+631

num_found == 0

Trade-Lookup

4

+641

num_trades_found == 0

Trade-Update

2

+1021

num_updated == 0

Trade-Update

3

+1031

num_found == 0

If a transaction processing monitor (hereinafter referred to as TM) is used it must be commerciallyavailable software which provides the following features/functionality:
Operation - The TM must allow for:

request/service prioritization

multiplexing/de multiplexing of requests/services



automatic load balancing



reception, queuing, and execution of multiple requests/services concurrently

Security - The TM must allow for:

the ability to validate and authorize execution of each service at the time the service is requested.



the restriction of administrative functions to authorized users.

Administration/Maintenance - The TM must have the predefined capability to perform centralized,
non programmatic (i.e., must be implemented in the standard product and not require programming)and dynamic configuration management of TM resources including hardware, network, services(single or group), queue management prioritization rules, etc.
Recovery - The TM must have the capability to:post error codes to an application
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 78 of 287



detect and terminate long-running transactions based on predefined time-out intervals

Application Transparency - The message context(s) that exist between the client and server application
programs must be managed solely by the TM. The client and server application programs must nothave any knowledge of the message context or the underlying communication mechanisms that
support that context.
The following are examples of implementations that are non-compliant with theApplication Transparency requirement.
Comment 1:

1.

Client and server application programs use the same identifier (e.g., handle or pointer) to maintainthe message context for multiple transactions.

2.

Change and/or recompilation of the client and/or server application programs is required when
the number of queues or equivalent data structures used by the TM to maintain the message context
between the client and server application programs is changed by TM administration.

Comment 2: The intent of this clause is to encourage the use of general purpose, commercially available

transaction monitors, and to exclude special purpose software developed for benchmarking or otherlimited use. It is recognized that implementations of features and functionality described above varyacross vendors' architectures. Such differences do not preclude compliance with the requirements ofthis clause.

3.2.2

Customer Partitioning and Generating Transaction Inputs

3.2.2.1

If customer partitioning is being used and the Frame is Customer Initiated, EGenDriverCE will apply
the following rules whenever generating a customer identifier, account identifier or customer tax
identifier:

50% of the time the data is selected from the partition’s range of customers.



50% of the time the data is selected from the entire range of customers.

If customer partitioning is not being used, or the Frame is not Customer Initiated, EGenDriverCE will
generate customer identifiers, account identifiers and customer tax identifiers from the entire range ofcustomers.

3.3

The Transactions
The TPC-E benchmark consists of eleven Transactions, and one cleanup Transaction. To generate areasonably balanced workload that resembles real production environments, the Transactions have tocover a wide variety of system functions. Ten of the Transactions follow a specific mix to generate thedesired workload while keeping the benchmark environment simple, repeatable and easy to execute.
The eleventh Transaction is not part of the Transaction Mix, but is executed at fixed intervals. This
Transaction, called “Data-Maintenance”, simulates administrative updates to tables that are nototherwise modified by the Transactions in the mix. A cleanup Transaction, called “Trade-Cleanup”, isprovided to clean up pending and submitted trades that may exist from an earlier run.
One of the key performance characteristics of database systems is the ratio of reads and writes
generated by the workload. To emulate such a ratio, TPC-E has defined Transactions with read-onlycharacteristics as well as Transactions with read-write characteristics. In addition, the Transactions
apply varying loads on the processor.
The variety of processor, IO, and execution frequency requirements for the Transactions allows thebenchmark to emulate a real environment with heavy processor utilization while maintaining areasonable IO load in a simple benchmark configuration.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 79 of 287

The Transactions in the mix can be grouped into three categories:

Customer Initiated: These Transactions simulate customer interactions with the system and are
initiated by the Customer Emulator component of the benchmark Driver.



Brokerage Initiated: These Transactions simulate broker interactions with the system and are
initiated by the Customer Emulator component of the benchmark Driver.

Market Triggered: These Transactions simulate the behavior of the market and are triggered by
the Market Exchange Emulator component of the benchmark Driver.

In addition to the mix of transactions above, the benchmark defines a time triggered Data-Maintenancetransaction, which is initiated at fixed time intervals as defined in Clause 6.3.3. Also defined is a TradeCleanup transaction (see clause 6.3.4), which may not be executed within a Test Run, but must be
executed once before a Test Run if the database is not in its initially populated state (i.e., if any priorruns have been performed on the database).
The following summary table lists the basic characteristics of the transactions:

3.3.1

Transaction

WeightAccessCategory

FramesDefinition

Broker-Volume

Mid to Heavy

Read-only

Brokerage Initiated1

Clause 3.3.1

Customer-Position

Mid to Heavy

Read-only

Customer Initiated3

Clause 3.3.2

Market-Feed

MediumRead-write

Market Triggered

1

Clause 3.3.3Market-Watch

MediumRead-only

Customer Initiated1

Clause 3.3.4

Security-Detail

MediumRead-only

Customer Initiated1

Clause 3.3.5

4

Clause 3.3.6

Brokerage Initiated for
Frames 1 & 3

Trade-Lookup

MediumRead-only

Trade-Order

Heavy

Read-write

Customer Initiated6

Clause 3.3.7

Trade-Result

Heavy

Read-write

Market Triggered

6

Clause 3.3.8

Trade-Status

Light

Read-only

Customer Initiated1

Clause 3.3.9

3Clause 3.3.10

Customer Initiated for
Frames 2 & 4

Brokerage Initiated for
Frames 1& 3

Trade-Update

MediumRead-write

Data-MaintenanceLight

Read-write

Time Triggered

1

Clause 3.3.11

Trade-Cleanup

MediumRead-write

Run once before Test Run

1

Clause 3.3.12

Customer Initiated for
Frame 2The Broker-Volume Transaction
The Broker-Volume Transaction is designed to emulate a brokerage house’s “up-to-the-minute”
internal business processing. An example of a Broker-Volume Transaction would be a manager
generating a report on the current performance potential of various brokers.
Broker-Volume is invoked by EGenDriverCE. It consists of a single Frame. The Transaction searches
the pending limit orders to find orders that are associated with a given list of brokers responsible forstocks of a given sector. The value of each order is calculated based upon bid price and quantity ofshares and added to the running total volume for the appropriate broker. The list of brokers with theirassociated total volume sorted in descending volume order is returned.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 80 of 287

3.3.1.1

Broker-Volume Transaction Parameters

The inputs to the Broker-Volume Transaction are generated by the EGenDriverCE code in
CETxnInputGenerator.cpp and the data structures defined in TxnHarnessStructs.h must be used tocommunicate the input and output parameters.
Broker-Volume Interfaces

Module/Data Structure

CE Input generation

GenerateBrokerVolumeInput()

Transaction Input/Output Structure

TBrokerVolumeTxnInput
TBrokerVolumeTxnOutput

Frame 1 Input/Output Structure

TBrokerVolumeTxnInput
TBrokerVolumeFrame1Output

Broker-Volume Transaction Parameters:
Parameter

Direction

Description

broker_list[ ]INA list of twenty to forty distinct broker name strings as defined by B_NAME in
BROKER table. Names are randomly selected from the broker range, with, uniform
distribution. The list size is determined by the first null input name in thebroker_list array.

sector_nameIN

A randomly selected sector name string as defined in SC_NAME in SECTOR tableusing uniform distribution.

list_len

OUT

Number of items in the list being returned.

statusOUT

Code indicating the execution status for this transaction.

OUT

A list of numbers, sorted in descending order, representing the sum of all traderequest values (TR_QTY * TR_BID_PRICE) in the TRADE_REQUEST table forstocks in a given sector grouped by broker names provided by broker_list. The list
size is determined by list_len parameter.

volume[ ]3.3.1.2

Broker-Volume Transaction Database Footprint

This Transaction is read-only and makes no changes to the database. The Broker-Volume Database
Footprint is as follows:
Broker-Volume Database Footprint
Frame
Table

Column1

BROKER
TRADE_REQUEST

B_NAME

TR_BID_PRICE Reference
TR_QTY

Transaction Control

3.3.1.3

ReturnReference
Start
CommitBroker Volume Transaction Frame 1 of 1

The database access methods used in Frame 1 are all Returns.
The EGenTxnHarness controls the execution of Frame 1 as follows:

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 81 of 287

{
invoke (Broker-Volume_Frame-1)
if (list_len < 0) or (list_len > max_broker_list_len) then{status = -111}}
Broker-Volume Frame 1 of 1 Parameters:
Parameter

Direction

Description

broker_list[ ]INA list of twenty to forty distinct broker name strings as
defined by B_NAME in BROKER table. Names are randomly
selected from the broker range, with, uniform distribution.
The list size is determined by the first null input name in thebroker_list array.

sector_nameIN

A randomly selected sector name string as defined in
SC_NAME in SECTOR table using uniform distribution.

broker_name[ ]OUT

A list of broker name strings sorted in descending order of
the “volume” associated with the broker. The list size isdetermined by list_len parameter.

list_len

OUT

Number of items in the list being returned.

OUT

A list of numbers, sorted in descending order, representing
the sum of all trade request values (TR_QTY *TR_BID_PRICE) in the TRADE_REQUEST table for stocks ina given sector grouped by broker names provided bybroker_list. The list size is determined by list_len parameter.

volume[ ]Broker-Volume_Frame-1 Pseudo-code: Broker Volume{
start transaction// Should return 0 to 40 rows
selectbroker_name[] = B_NAME,
volume[]= sum(TR_QTY * TR_BID_PRICE)fromTRADE_REQUEST,SECTOR,
INDUSTRYCOMPANY,BROKER,
SECURITY
where
TR_B_ID = B_ID and
TR_S_SYMB = S_SYMB and
S_CO_ID = CO_ID and

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 82 of 287

Broker-Volume_Frame-1 Pseudo-code: Broker Volume
CO_IN_ID = IN_ID and
SC_ID = IN_SC_ID and
B_NAME in (broker_list) and
SC_NAME = sector_namegroup by
B_NAMEorder by
2 DESC// row_count will frequently be zero near the start of a Test Run when// TRADE_REQUEST table is mostly empty.
list_len = row_countcommit transaction

}

3.3.2

The Customer-Position Transaction
The Customer-Position Transaction is designed to emulate the process of retrieving the customer’s
profile and summarizing their overall standing based on current market values for all assets. This isrepresentative of the work performed when a customer asks the question “What am I worth today?”Customer-Position is invoked by EGenDriverCE. It consists of three Frames, (Frame 2 and 3 aremutually exclusive). The customer is specified either by a customer ID or a customer tax ID. If thecustomer ID passed into the Transaction is 0, then the customer tax ID is used to look up the customer
ID. Detailed information about the customer’s profile is retrieved. In addition, for each of thecustomer’s accounts, the cash balance of the account and the total current market value of all holdingsin the account are returned.
If a history of trading activity has been requested, information is retrieved on the ten most recent trades
for a randomly chosen account among the customer’s accounts.

3.3.2.1

Customer-Position Transaction Parameters

The inputs to the Customer Position Transaction are generated by the EGenDriverCE code in
CETxnInputGenerator.cpp and the data structures defined in TxnHarnessStructs.h must be used tocommunicate the input and output parameters.
Customer-Position Interfaces

Module/Data Structure

CE Input generation

GenerateCustomerPositionInput()

Transaction Input/Output Structure

TCustomerPositionTxnInput
TCustomerPositionTxnOutput

Frame 1 Input/Output Structure

TCustomerPositionFrame1Input
TCustomerPositionFrame1Output

Frame 2 Input/Output Structure

TCustomerPositionFrame2Input
TCustomerPositionFrame2Output

Frame 3 Input/Output Structure<none>TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 83 of 287

Customer-Position Transaction Parameters:
Parameter

Direction

Description

acct_id_idx

INIndex to one of the customer’s accounts. This
indexed account will be used in frame 2 if
get_history is TRUE.

cust_idIN

Customer id or 0, selected by the driver.

get_history

IN

Selected by the driver to be 1 if Frame 2 is to be
invoked or 0 if not.

tax_idIN

Customer tax id or empty string selected by thedriver.

acct_id[max_acct_len]

OUT

Array of customer account IDs.

acct_len

OUT

Number of customer accounts (max_acct_len (10) or
less)

asset_total[max_acct_len]

OUT

Array of asset totals for each customer account.

c_ad_id

OUT

Customer address identifier.

c_area_1

OUT

Area code for customer’s first phone number.

c_area_2

OUT

Area code for customer’s second phone number.

c_area_3

OUT

Area code for customer’s third phone number.

c_ctry_1

OUT

Country code for customer’s first phone number.

c_ctry_2

OUT

Country code for customer’s second phone number.

c_ctry_3

OUT

Country code for customer’s third phone number.

c_dob

OUT

Customer date of birth.

c_email_1

OUT

Customer’s first email address.

c_email_2

OUT

Customer’s second email address.

c_ext_1

OUT

Customer’s extension for the first phone number.

c_ext_2

OUT

Customer’s extension for the second phone number.

c_ext_3

OUT

Customer’s extension for the third phone number.

c_f_name

OUT

Customer first name.

c_gndrOUT

Customer gender.

c_l_name

OUT

Customer last name.

c_local_1

OUT

Customer’s first phone number.

c_local_2

OUT

Customer’s second phone number.

c_local_3

OUT

Customer’s third phone number.

c_m_name

OUT

Customer middle name.

c_st_id

OUT

Customer Status id.

c_tierOUT

Customer tier.

cash_bal[max_acct_len]

OUT

Array of cash balances for each customer account.

hist_dts[max_hist_len]

OUT

Date for each transaction date from the transaction
history

hist_len

OUT

Number of records from the transaction history

qty[max_hist_len]

OUT

Number of shares involved in each event from
history

statusOUT

Code indicating the execution status for thistransaction.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 84 of 287

3.3.2.2

symbol[max_hist_len]

OUT

Security involved in each event from history.

trade_id[max_hist_len]

OUT

Trade ID for each event from history.

trade_status[max_hist_len]

OUT

Trade Status for each event from history.

Customer-Position Transaction Database Footprint

The Customer-Position Database Footprint is as follows:
Customer-Position Database Footprint
Frame
Table Name

Column12*

C_AD_ID

ReturnC_AREA_1

ReturnC_AREA_2

ReturnC_AREA_3

ReturnC_CTRY_1

ReturnC_CTRY_2

ReturnC_CTRY_3

ReturnC_DOB

ReturnC_EMAIL_1

ReturnC_EMAIL_2

ReturnC_EXT_1

ReturnC_EXT_2

ReturnC_EXT_3

ReturnC_F_NAME

ReturnC_GNDR

ReturnC_L_NAME

ReturnC_LOCAL_1

ReturnC_LOCAL_2

ReturnC_LOCAL_3

ReturnC_M_NAME

Return

C_ST_ID

ReturnC_TIER

ReturnCA_BAL

ReturnCA_ID

ReturnHOLDING_SUMMARY

HS_QTY

Reference

LAST_TRADE

LT_PRICE

Reference

STATUS_TYPE

ST_NAME

ReturnTRADE_HISTORY

TH_DTS

Return

T_ID

ReturnT_QTY

ReturnCUSTOMERCUSTOMER_ACCOUNT

TRADE

3*

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 85 of 287

T_S_SYMBReturnStart

Transaction Control

3.3.2.3

CommitCommitCustomer-Position Transaction Frame 1 of 3

If the cust_id input parameter is set to 0, the Frame must use the tax_id input parameter to search the
CUSTOMER table and find the ID of the customer. The Frame retrieves the detailed customer
information and finds the cash balance for each of the customer’s accounts as well as the total value ofthe holdings in each account. In addition to the detailed customer information, the Frame returns a listof accounts and their associated cash balance and asset value sorted by asset value.
The database access methods used in Frame 1 are Reference and Return.
The EGenTxnHarness controls the execution of Frame 1 as follows:{
invoke (Customer-Position_Frame-1)
if (acct_len < 1) or (acct_len > max_acct_len) then{status = -211)}
Customer-Position Frame 1 of 3 Parameters:
Parameter

Direction

Description

cust_id

IN/OUT

Customer id or 0, selected by the driver. When cust_id is
not 0, the rules for determining the range of available
customer identifiers are described in clause 3.2.2.1.

tax_idIN

Customer tax id or empty string selected by the driver.
When tax_id is not the empty string, the rules fordetermining the range of available customer tax identifiers
are described in clause 3.2.2.1.

acct_id[max_acct_len]

OUT

Array of customer account IDs.

acct_len

OUT

Number of customer accounts (max_acct_len (10) or less).

asset_total[max_acct_len]

OUT

Array of asset totals for each customer account.

c_ad_id

OUT

Customer address identifier.

c_area_1

OUT

Area code for customer’s first phone number.

c_area_2

OUT

Area code for customer’s second phone number.

c_area_3

OUT

Area code for customer’s third phone number.

c_ctry_1

OUT

Country code for customer’s first phone number.

c_ctry_2

OUT

Country code for customer’s second phone number.

c_ctry_3

OUT

Country code for customer’s third phone number.

c_dob

OUT

Customer date of birth.

c_email_1

OUT

Customer’s first email address.

c_email_2

OUT

Customer’s second email address.

c_ext_1

OUT

Customer’s extension for the first phone number.

c_ext_2

OUT

Customer’s extension for the second phone number.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 86 of 287

c_ext_3

OUT

Customer’s extension for the third phone number.

c_f_name

OUT

Customer first name.

c_gndrOUT

Customer gender.

c_l_name

OUT

Customer last name.

c_local_1

OUT

Customer’s first phone number.

c_local_2

OUT

Customer’s second phone number.

c_local_3

OUT

Customer’s third phone number.

c_m_name

OUT

Customer middle name.

c_st_id

OUT

Customer Status id.

c_tierOUT

Customer tier.

cash_bal[max_acct_len]

OUT

Array of cash balances for each customer account.

Customer-Position_Frame-1 Pseudo-code: Get the customer's total assets{
start transaction
if (cust_id == null_cust_id) then {selectcust_id = C_ID
from
CUSTOMER
where
C_TAX_ID = tax_id}
selectc_st_id= C_ST_ID,

c_l_name= C_L_NAME,

c_f_name= C_F_NAME,

c_m_name= C_M_NAME,

c_gndr= C_GNDR,

c_tier

= C_TIER,

c_dob= C_DOB,c_ad_id= C_AD_ID,

c_ctry_1= C_CTRY_1,

c_area_1= C_AREA_1,

c_local_1 = C_LOCAL_1,
c_ext_1= C_EXT_1,

c_ctry_2= C_CTRY_2,

c_area_2= C_AREA_2,

c_local_2 = C_LOCAL_2,
c_ext_2= C_EXT_2,

c_ctry_3= C_CTRY_3,

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 87 of 287

Customer-Position_Frame-1 Pseudo-code: Get the customer's total assets
c_area_3= C_AREA_3,

c_local_3 = C_LOCAL_3,
c_ext_3= C_EXT_3,

c_email_1 = C_EMAIL_1,
c_email_2 = C_EMAIL_2
from
CUSTOMER
where
C_ID = cust_id// Should return 1 to max_acct_len (10).
select first max_acct_len rows
acct_id[]= CA_ID,

cash_bal[]= CA_BAL,

assets_total[] = ifnull((sum(HS_QTY * LT_PRICE)),0)
from
CUSTOMER_ACCOUNT left outer join
HOLDING_SUMMARY on HS_CA_ID = CA_ID,
LAST_TRADE
where
CA_C_ID= cust_id and

LT_S_SYMB = HS_S_SYMB
group by
CA_ID, CA_BAL
order by
3 asc
acct_len = row_count}

3.3.2.4

Customer-Position Transaction Frame 2 of 3

This Frame is only executed if the Transaction parameter get_history value is set to TRUE. Using thecustomer account ID the Frame must search the TRADE and TRADE_HISTORY tables to find up to 30
history rows that correspond with the 10 most recent trades executed by the customer account. For
each event the Frame must return the T_ID, T_S_SYMB, T_QTY, TH_DTS, and ST_NAME for all eventsin a descending order of date found in TH_DTS. This Frame completes the work and commits theTransaction
The database access methods used in Frame 2 are all Returns.
The EGenTxnHarness controls the execution of Frame 2 as follows:

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 88 of 287

{
if (get_history == 1) then{frame2.acct_id = frame1.acct_id[acct_id_idx]

invoke (Customer-Position_Frame-2)

if (hist_len < 10) or (hist_len > max_hist_len) then{status = -221
}
exit
}
}
Customer-Position Frame 2 of 3 Parameters:
Parameter

Direction

Description

acct_idIN

Customer account identifier

hist_dts[max_hist_len]

OUT

Date for each transaction date from the transaction history

hist_len

OUT

Number of records from the transaction history, at most
max_hist_len which is 30.

qty[max_hist_len]

OUT

Number of shares involved in each event from history

symbol[max_hist_len]

OUT

Security involved in each event from history.

trade_id[max_hist_len]

OUT

Trade ID for each event from history.

trade_status[max_hist_len]

OUT

Trade Status for each event from history.

Customer-Position_Frame-2 Pseudo-code: Get the customer's trade history{// Should return 10 to 30 rows.
select first 30 rows
trade_id[]= T_ID,symbol[]= T_S_SYMB,

qty[]= T_QTY,

trade_status[] = ST_NAME,
hist_dts[]= TH_DTS

from(select first 10 rows
T_ID as ID
from
TRADE

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 89 of 287

Customer-Position_Frame-2 Pseudo-code: Get the customer's trade history
where
T_CA_ID = acct_id
order by T_DTS desc) as T,
TRADE,TRADE_HISTORY,STATUS_TYPE
where
T_ID = ID and
TH_T_ID = T_ID and
ST_ID = TH_ST_ID
order by
TH_DTS desc
hist_len = row_countcommit transaction}

3.3.2.5

Customer-Position Transaction Frame 3 of 3

This Frame is only executed if get_history Transaction input parameter is set to FALSE. The Frame
simply Commits the Transaction started in Frame 1 and returns the status.
There are no database access methods used in Frame 3. This Frame is only using Transaction control
operations.
The EGenTxnHarness controls the execution of Frame 3 as follows:{
if (get_history != 1) then{invoke (Customer-Position_Frame-3)}}Customer-Position_Frame-3: End database transaction{
commit transaction

}

3.3.3

The Market-Feed Transaction
The Market-Feed Transaction is designed to emulate the process of tracking the current market
activity. This is representative of the brokerage house processing the “ticker-tape” from the market
exchange.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 90 of 287

Market-Feed is invoked by EGenDriverMEE. It consists of a single Frame. The Transaction receives thelatest trade activity information (symbol, price, quantity, etc.) from the market exchange. As a result ofprocessing the ticker feed, the prices for securities will increase or decrease. These changes in price maytrigger pending limit orders. If triggered, limit order processing is performed by sending details of the
trade request to the MEE, via the SendToMarketFromFrame interface.
Each Market-Feed ticker consists of 20 entries (max_feed_len constant in TxnHarnessStructs.h). Ten ofthese entries are a result of trades submitted to the MEE by this brokerage house. The remaining entries
are generated by the MEE to simulate the reporting of trades from other brokerage houses. The MarketFeed Transaction is allowed to process any number of ticker elements (from one to all) per Database
Transaction.
3.3.3.1

Market-Feed Transaction Parameters

The inputs to the Market-Feed Transaction are generated by the EGenDriverMEE code in MEE.cpp.
The data structures defined in TxnHarnessStructs.h must be used to communicate the input and output
parameters.
Market-Feed Interfaces

Module/Data Structure

MEE Input generation

CMEESUTInterface::MarketFeed()Transaction Input/Output Structure

TMarketFeedTxnInput
TMarketFeedTxnOutput

Frame 1 Input/Output Structure

TMarketFeedFrame1Input
TMarketFeedFrame1Output

Market-Feed Transaction Parameters:

3.3.3.2

Parameter

Direction

Description

price_quote[ ]INA list of numeric prices the Market Exchange Emulator generated for eachentry on the ticker list. Each security’s price fluctuates between a low and highprice, the fluctuation has a predefined frequency.

status_submitted

IN

The string ID value for the STATUS_TYPE Submitted status.

symbol[ ]INA list of strings containing the Security Symbol for each security on the ticker.
The security symbol string follows the definition of LT_S_SYMB in the
LAST_TRADE table. The ticker was generated by the Market Exchange
Emulator.

trade_qty[ ]INA list of numbers representing the number of shares of a security that weretraded for this ticker entry. The trade_qty is the same as the trade_qty
requested in the Trade Request.

type_limit_buy

INThe string ID value for the TRADE_TYPE Limit-Buy type.

type_limit_sell

IN

The string ID value for the TRADE_TYPE Limit-Sell type.

type_stop_loss

IN

The string ID value for the TRADE_TYPE Stop-Loss type.

unique_symbols

IN

The number of unique security symbols in the ticker stream.

send_len

OUT

Length of the output array. Ranges from 0 upwards. Average is about 4.

statusOUT

Code indicating the execution status for this transaction.

Market-Feed Transaction Database Footprint

The Market-Feed Database Footprint is as follows:
Market-Feed Database Footprint
Table Name

ColumnFrame

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 91 of 287

1

LAST_TRADE

TRADE
TRADE_HISTORY

TRADE_REQUEST

LT_DTS

ModifyLT_PRICE

ModifyLT_VOL

Reference
ModifyT_DTS

Modify*T_ST_ID

Modify*

1 Row

Add*

TR_BID_PRICE

ReturnTR_QTY

Return

TR_T_ID

ReturnTR_TT_ID

ReturnRow(s)

Remove*Start
Commit(1 –max_feed_len)

Transaction Control

3.3.3.3

Market-Feed Transaction Frame 1 of 1

Using the entries in the ticker list, the Frame is responsible for:

modifying the rows in the LAST_TRADE table with the new prices, the new daily volumes andthe new last trade dates

identifying any pending limit orders that should be triggered by these ticker prices, processing
them, and submitting them to the MEE

The database access methods used in Frame 1 are Modifies, Adds, References, Removes and Returns.
The EGenTxnHarness controls the execution of Frame 1 as follows:{

invoke (Market-Feed_Frame-1)
if (num_updated < unique_symbols) then{status = -311;}}
Market-Feed Frame 1 of 1 Parameters:
Parameter

Direction

Description

price_quote[ ]INA list of numeric prices the Market Exchange Emulator generated foreach entry on the ticker list. Each security’s price fluctuates between a
low and high price, the fluctuation has a predefined frequency.

status_submitted

IN

The string ID value for the STATUS_TYPE Submitted status.

symbol[ ]INA list of strings containing the Security Symbol for each security on theticker. The security symbol string follows the definition of LT_S_SYMB
in the LAST_TRADE table. The ticker was generated by the Market

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 92 of 287

Exchange Emulator.
trade_qty[ ]INA list of numbers representing the number of shares of a security thatwere traded for this ticker entry. The trade_qty is the same as thetrade_qty requested in the Trade Request.

type_limit_buy

INThe string ID value for the TRADE_TYPE Limit-Buy type.

type_limit_sell

IN

The string ID value for the TRADE_TYPE Limit-Sell type.

type_stop_loss

IN

The string ID value for the TRADE_TYPE Stop-Loss type.

num_updated

OUT

Number of LAST_TRADE rows updated.

send_len

OUT

Length of the output arrays. Ranges from 0 upwards. Average is about
4.

Market-Feed_Frame-1 Pseudo-code: Record the stock price and process any
pending limit orders which are triggered by the ticker price.

{declare now_dts DATETIME
declare TradeRequestBuffer[]
declare req_price_quote S_PRICE_T
declare req_trade_id TRADE_T
declare req_trade_qty S_QTY_T
declare req_trade_type CHAR(3)declare rows_updated int
declare rows_sent int
get_current_dts(now_dts)
rows_updated = 0
for (i = 1, i<=max_feed_len, i++) {start transaction
rows_sent = 0
update
LAST_TRADE
set
LT_PRICE = price_quote[i],LT_VOL = LT_VOL + trade_qty[i],LT_DTS = now_dts
where
LT_S_SYMB = symbol[i]rows_updated = rows_updated + row_countdeclare request_list cursor for
select
TR_T_ID,

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 93 of 287

Market-Feed_Frame-1 Pseudo-code: Record the stock price and process any
pending limit orders which are triggered by the ticker price.
TR_BID_PRICE,
TR_TT_ID,
TR_QTYfromTRADE_REQUEST
where
TR_S_SYMB = symbol[i] and ((TR_TT_ID = type_stop_loss and
TR_BID_PRICE >= price_quote[i]) or(TR_TT_ID = type_limit_sell and
TR_BID_PRICE <= price_quote[i]) or(TR_TT_ID = type_limit_buy and
TR_BID_PRICE >= price_quote[i]))open request_list
fetch fromrequest_list
into
req_trade_id,
req_price_quote,
req_trade_type,
req_trade_qty
do until (request_list.end_of_cursor) {update
TRADE
set
T_DTS

= now_dts,

T_ST_ID = status_submitted
where
T_ID = req_trade_id
deleteTRADE_REQUEST
where
current of request_list
insert into
TRADE_HISTORY
values (TH_T_ID = req_trade_id,
TH_DTS = now_dts,
TH_ST_ID = status_submitted)

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 94 of 287

Market-Feed_Frame-1 Pseudo-code: Record the stock price and process any
pending limit orders which are triggered by the ticker price.
TradeRequestBuffer[rows_sent].symbol = symbol[i]TradeRequestBuffer[rows_sent].trade_id = req_trade_id
TradeRequestBuffer[rows_sent].price_quote = req_price_quote
TradeRequestBuffer[rows_sent].trade_qty = req_trade_qty
TradeRequestBuffer[rows_sent].trade_type = req_trade_type
rows_sent = rows_sent + 1
fetch fromrequest_list
into
req_trade_id,
req_price_quote,
req_trade_type,
req_trade_qty} /* end of cursor fetch loop */close request_list
commit transaction
send_len = send_len + rows_sent//send triggered trades to the Market Exchange Emulator//via the SendToMarket interface.

This should be done//after the related database changes have committed
For (j=0; j<rows_sent; j++){SendToMarketFromFrame(TradeRequestBuffer[j].symbol,
TradeRequestBuffer[j].trade_id,
TradeRequestBuffer[j].price_quote,
TradeRequestBuffer[j].trade_qty,
TradeRequestBuffer[j].trade_type);}} /* end of ticker loop */

}

3.3.4

The Market-Watch Transaction
The Market-Watch Transaction is designed to emulate the process of monitoring the overall
performance of the market by allowing a customer to track the current daily trend (up or down) of acollection of securities. The collection of securities being monitored may be based upon a customer’scurrent holdings, a customer’s watch list of prospective securities, or a particular industry.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 95 of 287

Market-Watch is invoked by EGenDriverCE. It consists of a single Frame. This Transaction calculates
the percentage change in value of the market capitalization of a collection of securities at a chosen day’s
closing prices compared to the current market prices. The chosen day is non-uniformly selected fromthe 1305 days of market data that was loaded during initial population of the database. The calculation
is done by looking at the chosen day’s closing price for each security in the list and multiplying that by
the number of outstanding shares for that security. This product is added to a running total for the
chosen day’s closing market capitalization. In addition, the current price for each security in the list ismultiplied by the number of outstanding shares for that security. This product is added to a runningsum for the current market capitalization. The difference between the total market capitalization forthe chosen day's closing and the current total, expressed as a percentage, is returned.
The Transaction supports this market watch calculation on a group of securities chosen based on thefollowing list of criteria:

3.3.4.1

Prospective-Watch - The collection of securities is chosen using all the securities in a customer’s
watch list. The rules for determining the range of available customers, and thereby watch lists, aredescribed in clause 3.2.2.1.

Industry-Watch - The collection of securities is chosen using all the securities in an industry
belonging to companies within a specified range. The industry name is chosen at random from thepossible industry names using a uniform distribution.

Portfolio-Watch - The collection of securities is chosen using all the securities that are held in acustomer’s account. The rules for determining the range of available customers are described inclause 3.3.1.1. The customer account identifier is chosen at random from all the possible accounts
for that customer using a uniform distribution.

Market-Watch Transaction Parameters

The inputs to the Market-Watch Transaction are generated by the EGenDriverCE code in
CETxnInputGenerator.cpp. The data structures defined in TxnHarnessStructs.h must be used tocommunicate the input and output parameters.
Market-Watch Interfaces

Module/Data Structure

CE Input generation

GenerateMarketWatchInput()

Transaction Input/Output Structure

TMarketWatchTxnInput
TMarketWatchTxnOutput

Frame 1 Input/Output Structure

TMarketWatchFrame1Input
TMarketWatchFrame1Output

Market-Watch Transaction Parameters:
Parameter

Direction

DescriptionIN

A single customer is chosen non-uniformly by customer tier, from therange of available customers. The rules for determining the range ofavailable customers are described in clause 3.2.2.1. A single customer
account id, as defined by CA_ID in CUSTOMER_ACCOUNT, is chosen
at random, uniformly, from the range of customer account ids for the
chosen customer. This input will be used 35% of the time. The securities
collection will be all the securities held this customer account. The other
65% of the time when this input is not being used its value will be 0.

cust_idIN

A number randomly selected from the possible customer identifiers as
defined by C_ID in CUSTOMER table using a non-uniform by customer
tier distribution. (The rules for determining the range of possible
customer identifiers are described in clause 3.2.2.1.) This input will be
used 60% of the time. The securities collection will be all the securities inthis customer’s watch list. The other 40% of the time when this input is
not being used its value will be 0.

ending_co_id

INCompany identifier of the last company in the range of 5,000 companies

acct_id

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 96 of 287

to be searched for companies in IN_NAME industry. The value will bestarting_co_id + 4,999. This input will only be used when industry_nameis used which is 5% of the time. The other 95% of the time when this
input is not being used its value will be zero.

3.3.4.2

industry_nameIN

A randomly selected industry name string as defined in IN_NAME in
INDUSTRY table using uniform distribution. This input will be used 5%of the time. The securities collection will be all the securities of companies
in this industry. The other 95% of the time when this input is not being
used its value will be an empty string.

start_date

INA date non-uniformly selected from the 1305 days in the
DAILY_MARKET table. The closing price of securities on this date isused in the market capitalization calculations.

starting_co_id

IN

A number randomly selected from the range of possible company
identifiers minus 4,999. Company identifier of the first company in therange of 5,000 companies to be searched for companies in IN_NAME
industry. This input will only be used when industry_name is usedwhich is 5% of the time. The other 95% of the time when this input is not
being used its value will be zero.

pct_change

OUT

Numeric value calculated during the transaction by finding thepercentage change from chosen day’s close of business capitalization forthe collection of securities and the current capitalization for the collectionof securities.

statusOUT

Code indicating the execution status for this transaction.

Market-Watch Transaction Database Footprint

The Market-Watch Database Footprint is as follows:
Market-Watch Database Footprint
Frame
Table

Column1
CO_ID

Reference*

CO_IN_ID

Reference*

DAILY_MARKET

DM_CLOSE

Reference

HOLDING_SUMMARY

HS_S_SYMB

Reference*

IN_ID

Reference*

IN_NAME

Reference*

LT_PRICE

Reference

S_CO_ID

Reference*

COMPANYINDUSTRY
LAST_TRADE

SECURITY

WATCH_ITEM
WATCH_LIST

Transaction Control

3.3.4.3

S_NUM_OUT Reference
S_SYMB

Reference*

WI_S_SYMB

Reference*

WL_C_ID

Reference*

WL_ID

Reference*
Start
CommitMarket-Watch Transaction Frame 1 of 1

The database access methods used in Frame 1 are all References.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 97 of 287

The EGenTxnHarness controls the execution of Frame 1 as follows:{
if (acct_id != 0) or (cust_id != 0) or (industry_name != “”) then{invoke (Market-Watch_Frame-1)}
else{
status = -411}}
Market-Watch Frame 1 of 1 Parameters:
Parameter

Direction

DescriptionIN

A single customer is chosen non-uniformly by customer tier, from therange of available customers. The rules for determining the range ofavailable customers are described in clause 3.2.2.1. A single customer
account id, as defined by CA_ID in CUSTOMER_ACCOUNT, is chosen
at random, uniformly, from the range of customer account ids for the
chosen customer. This input will be used 35% of the time. The securities
collection will be all the securities held this customer account. The other
65% of the time when this input is not being used its value will be 0.

IN

A number randomly selected from the possible customer identifiers as
defined by C_ID in CUSTOMER table using a non-uniform by customer
tier distribution. (The rules for determining the range of possible
customer identifiers are described in clause 3.2.2.1.) This input will be
used 60% of the time. The securities collection will be all the securities inthis customer’s watch list. The other 40% of the time when this input is
not being used its value will be 0.

INCompany identifier of the last company in the range of 5,000 companies
to be searched for companies in IN_NAME industry. The value will bestarting_co_id + 4,999. This input will only be used when industry_nameis used which is 5% of the time. The other 95% of the time when this
input is not being used its value will be zero.

industry_nameIN

A randomly selected industry name string as defined in IN_NAME in
INDUSTRY table using uniform distribution. This input will be used 5%of the time. The securities collection will be all the securities of companies
in this industry. The other 95% of the time when this input is not being
used its value will be an empty string.

start_date

INA date non-uniformly selected from the 1305 days in the
DAILY_MARKET table. The closing price of securities on this date isused in the market capitalization calculations

IN

A number randomly selected from the range of possible company
identifiers minus 4,999. Company identifier of the first company in therange of 5,000 companies to be searched for companies in IN_NAME
industry. This input will only be used when industry_name is usedwhich is 5% of the time. The other 95% of the time when this input is not
being used its value will be zero.

OUT

Numeric value calculated during the transaction by finding thepercentage change from chosen day’s close of business capitalization forthe collection of securities and the current capitalization for the collectionof securities.

acct_id

cust_id

ending_co_id

starting_co_id

pct_change

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 98 of 287

Market-Watch_Frame-1 Pseudo-code: Build list of securities and computepercentage{
start transaction
if (cust_id != 0) then {declare stock_list cursor for
select
WI_S_SYMB
fromWATCH_ITEM,
WATCH_LIST
where
WI_WL_ID = WL_ID and
WL_C_ID = cust_id} else if (industry_name != "") then {declare stock_list cursor for
select
S_SYMB
from
INDUSTRY,COMPANY,SECURITY
where
IN_NAME = industry_name and
CO_IN_ID = IN_ID and
CO_ID between (starting_co_id and ending_co_id) and
S_CO_ID = CO_ID} else if (acct_id != 0) then {declare stock_list cursor for
select
HS_S_SYMBfromHOLDING_SUMMARY
where
HS_CA_ID = acct_id}
old_mkt_cap = 0.0
new_mkt_cap = 0.0
pct_change = 0.0
open stock_list
do until (stock_list.end_of_cursor) {fetch fromstock_list cursor
intosymbolselect

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 99 of 287

Market-Watch_Frame-1 Pseudo-code: Build list of securities and computepercentage
new_price = LT_PRICEfrom
LAST_TRADE
where
LT_S_SYMB = symbol
selects_num_out = S_NUM_OUT
from
SECURITY
where
S_SYMB = symbol// Closing price for this security on the chosen day.
selectold_price = DM_CLOSE
fromDAILY_MARKET
where
DM_S_SYMB = symbol and
DM_DATE = start_date
old_mkt_cap += s_num_out * old_pricenew_mkt_cap += s_num_out * new_price}if (old_mkt_cap != 0) then{// value of 0.00 for pct_change is valid
pct_change = 100 * (new_mkt_cap / old_mkt_cap - 1)}else{// no rows found, this can happen rarely when an account has no holdings
pct_change = 0.0}
close stock_list
commit transaction

}

3.3.5

The Security-Detail Transaction
The Security-Detail Transaction is designed to emulate the process of accessing detailed information ona particular security. This is representative of a customer doing research on a security prior to making adecision about whether or not to execute a trade.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 100 of 287

Security-Detail is invoked by EGenDriverCE. It consists of a single Frame. For a given security, theTransaction will return detailed security and company information, a list of the company’scompetitors, current and historical financial data, and recent news items about the company.
3.3.5.1

Security-Detail Transaction Parameters

The inputs to the Security-Detail Transaction are generated by the EGenDriverCE code in
CETxnInputGenerator.cpp and the data structures defined in TxnHarnessStructs.h must be used tocommunicate the input and output parameters.
Security-Detail Interfaces

Module/Data Structure

CE Input generation

GenerateSecurityDetailInput()

Transaction Input/Output Structure

TSecurityDetailTxnInput
TSecurityDetailTxnOutput

Frame 1 Input/Output Structure

TSecurityDetailFrame1Input
TSecurityDetailFrame1Output

Security-Detail Transaction Parameters:

3.3.5.2

Parameter

Direction

Description

access_lob_flag

IN

If 1, access the complete news articles for the company. If 0, access just thenews headlines and summaries.

max_rows_to_returnIN

An integer value, randomly selected between 5 and 20 with a uniform
distribution. This value determines how many rows must be returned
from the DAILY_MARKET table for this security.

start_dayIN

A date randomly selected from a uniform distribution of dates between 3
January 2000 and max_rows_to_return days before 1 January 2005. The
DAILY_MARKET table contains data for the period 3 January 2000 to 31
December 2004. The transaction will return max_rows_to_return worth ofrows from the DAILY_MARKET table for this security beginning with therow for start_day.

symbolIN

Security symbol, randomly selected from a uniform distribution.

last_volOUT

Volume of last trade

news_len

OUT

Number of news items returned in news array.

statusOUT

Code indicating the execution status for this transaction.

Security-Detail Transaction Database Footprint

The Security-Detail Database Footprint is as follows:
Security-Detail Database Footprint
Frame
Table

Column1

ADDRESSCOMPANY

AD_CTRY

ReturnAD_LINE1

ReturnAD_LINE2

ReturnAD_ZC_CODE

ReturnCO_CEO

ReturnCO_DESC

ReturnCO_NAME

ReturnTPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 101 of 287

COMPANY_COMPETITORDAILY_MARKET

EXCHANGE

FINANCIALINDUSTRY

LAST_TRADE

NEWS_ITEM

NEWS_XREF

CO_OPEN_DATE

ReturnCO_SP_RATE

ReturnCO_ST_ID

ReturnCP_CO_ID

Reference

CP_COMP_CO_ID

Reference

CP_IN_ID

Reference

DM_CLOSE

ReturnDM_DATE

ReturnDM_HIGH

ReturnDM_LOW

ReturnDM_VOL

ReturnEX_CLOSE

ReturnEX_DESC

ReturnEX_NAME

ReturnEX_NUM_SYMB

ReturnEX_OPEN

ReturnFI_ASSETS

ReturnFI_BASIC_EPS

ReturnFI_DILUT_EPS

ReturnFI_INVENTORY

ReturnFI_LIABILITY

ReturnFI_MARGIN

ReturnFI_NET_EARN

ReturnFI_OUT_BASIC

ReturnFI_OUT_DILUT

ReturnFI_QTR

ReturnFI_QTR_START_DATE

ReturnFI_REVENUE

ReturnFI_YEAR

ReturnIN_NAME

ReturnLT_OPEN_PRICE

ReturnLT_PRICE

ReturnLT_VOL

ReturnNI_AUTHOR

ReturnNI_DTS

ReturnNI_HEADLINE

Return*NI_ITEM

Return*NI_SOURCE

ReturnNI_SUMMARY

Return*NX_CO_ID

Reference

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 102 of 287

NX_NI_ID

Reference

S_52_WK_HIGH

ReturnS_52_WK_HIGH_DATE Return

SECURITY

ZIP_CODE

S_52_WK_LOW

ReturnS_52_WK_LOW_DATE

ReturnS_DIVIDEND

ReturnS_NAME

ReturnS_NUM_OUT

ReturnS_PE

ReturnS_START_DATE

ReturnS_YIELD

ReturnZC_DIV

ReturnZC_TOWN

ReturnStart
CommitTransaction Control

3.3.5.3

Security Detail Transaction Frame 1 of 1

The database access methods used in Frame 1 are Returns and References.
The EGenTxnHarness controls the execution of Frame 1 as follows:{
invoke (Security-Detail_Frame-1)
if (day_len < min_day_len) or (day_len > max_day_len) then{status = -511}
else if (fin_len != max_fin_len) then{status = -512}
else if (news_len != max_news_len) then{status = -513}}
Security-Detail Frame 1 of 1 Parameters:
Parameter

Direction

Description

access_lob_flag

IN

If 1, access the complete news articles for the company. If 0, access justthe news headlines and summaries.

max_rows_to_returnIN

An integer value, randomly selected between 5(iSecurityDetailMinRows) and 20 (iSecurityDetailMaxRows) with a

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 103 of 287

uniform distribution. This value determines how many rows must be
returned from the DAILY_MARKET table for this security.

start_dayIN

A date randomly selected from a uniform distribution of dates between
3 January 2000 and max_rows_to_return before 31 December 2004. The
DAILY_MARKET table contains data for the period 3 January 2000 to 31
December 2004. The transaction will return max_rows_to_return worthof rows from the DAILY_MARKET table for this security beginningwith the row for start_day.

symbolIN

Security symbol, randomly selected from a uniform distribution.

52_wk_high

OUT

Number showing 52 week high value for the security.

52_wk_high_date

OUT

Date showing when the 52_wk_high happened.

52_wk_low

OUT

Number showing 52 week low value for the security.

52_wk_low_date

OUT

Date showing when 52_wk_low happened.

ceo_name

OUT

CEO name, based on a list of distinct first and last names.

co_ad_ctry

OUT

Company country, USA or Canada

co_ad_div

OUT

Company county or state or province

co_ad_line1

OUT

Line 1 from a real company addressco_ad_line2

OUT

Line 2 from a real company addressco_ad_town

OUT

Company town

co_ad_zip

OUT

Company ZIP or postal code. Contains partly realistic US or Canadian
ZIP codes

co_desc

OUT

Short description of the company. Readable English text.

co_nameOUT

Company nameco_st_id

OUT

Contains the value ‘ST1’

cp_co_name[max_comp_len]

OUT

Array of strings containing the company names of competitors for thissecurities’ company. EGen loads the COMPANY_COMPETITOR tablewith 3 competitors for each company, so max_comp_len is 3.

cp_in_name[max_comp_len]

OUT

Array of strings containing the name of the industries in which
competitors compete with this securities’ company. EGen loads the
COMPANY_COMPETITOR table with 3 competitors for each company,
so max_comp_len is 3.

day[max_day_len]

OUT

Array of numbers containing daily data. max_day_len is a constant set
to 20.

day_len

OUT

Elements in the Day array

divid

OUT

Number containing security dividend

ex_ad_ctry

OUT

Exchange country

ex_ad_div

OUT

Exchange county or town or province

ex_ad_line1

OUT

Line 1 from real exchange addressex_ad_line2

OUT

Line 2 from real exchange addressex_ad_town

OUT

Exchange town

ex_ad_zip

OUT

Exchange ZIP code

ex_close

OUT

Time the exchange closes, 2 possible values.

ex_dateOUT

Date listed on exchange. Not earlier than Start_date

ex_desc

OUT

Description of the exchange

ex_nameOUT

Name of the exchange. 4 values

ex_num_symb

OUT

Number of securities traded

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 104 of 287

ex_open

OUT

Time the exchange opens

fin[max_fin_len]

OUT

Array of numbers with financial data. max_fin_len (20) is a constant set
in the EGen code.

fin_len

OUT

Length of the arraylast_open

OUT

Price of security at last exchange open

last_price

OUT

Price for security

last_volOUT

Volume of last trade

news[max_news_len]

OUT

Array of news items about the security’s company. max_new_len (2) is aconstant set in the EGen code.

news_len

OUT

Number of news items returned in news array.

num_out

OUT

Number of outstanding shares. Valid range is 4,000,000 to 9,500,000,000.

open_date

OUT

Date the company opened. Valid range is 01/01/1800 to build date

pe_ratio

OUT

Price/earning ratio. A random value between 1.00 and 120.00

s_nameOUT

Security name, 6850 distinct values

sp_rateOUT

Standards & Poor rating for the company, one of 39 values.

start_date

OUT

Date of trade started. Range id between 01/01/1900 and build date.

yield

OUT

Number containing yield for the security

Security-Detail_Frame-1 Pseudo-code: Get all details about the security{
Declare co_id

IDENT_T

start transaction
selects_name= S_NAME,

co_id= CO_ID,co_name= CO_NAME,

sp_rate= CO_SP_RATE

ceo_name= CO_CEO,co_desc= CO_DESC,

open_date= CO_OPEN_DATE,

co_st_id= CO_ST_ID,

co_ad_line1= CA.AD_LINE1,

co_ad_line2= CA.AD_LINE2,

co_ad_town= ZCA.ZC_TOWN,

co_ad_div= ZCA.ZC_DIV,

co_ad_zip= CA.AD_ZC_CODE,

co_ad_ctry= CA.AD_CTRY,

num_out= S_NUM_OUT,

start_date= S_START_DATE,

exch_date= S_EXCH_DATE,

pe_ratio= S_PE,TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 105 of 287

Security-Detail_Frame-1 Pseudo-code: Get all details about the security
52_wk_high= S_52WK_HIGH,

52_wk_high_date = S_52WK_HIGH_DATE,
52_wk_low= S_52WK_LOW,

52_wk_low_date= S_52WK_LOW_DATE,

divid= S_DIVIDEND,

yield= S_YIELD,

ex_ad_div= ZEA.ZC_DIV,

ex_ad_ctry= EA.AD_CTRY

ex_ad_line1= EA.AD_LINE1,

ex_ad_line2= EA.AD_LINE2,

ex_ad_town= ZEA.ZC_TOWN,

ex_ad_zip= EA.AD_ZC_CODE,

ex_close= EX_CLOSE,

ex_desc= EX_DESC,

ex_name= EX_NAME,

ex_num_symb= EX_NUM_SYMB,

ex_open= EX_OPEN

from
SECURITY,COMPANY,ADDRESS CA,ADDRESS EA,
ZIP_CODE ZCA,
ZIP_CODE ZEA,EXCHANGE
where
S_SYMB = symbol and
CO_ID = S_CO_ID and
CA.AD_ID = CO_AD_ID and
EA.AD_ID = EX_AD_ID and
EX_ID = S_EX_ID and
ca.ad_zc_code = zca.zc_code andea.ad_zc_code =zea.zc_code// Should return max_comp_len (3) rows
select first max_comp_len rows
cp_co_name[] = CO_NAME,
cp_in_name[] = IN_NAME
fromCOMPANY_COMPETITOR, COMPANY, INDUSTRY
where
CP_CO_ID = co_id and
CO_ID = CP_COMP_CO_ID and
IN_ID = CP_IN_ID// Should return max_fin_len (20) rows

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 106 of 287

Security-Detail_Frame-1 Pseudo-code: Get all details about the security
select first max_fin_len rows
fin[].year= FI_YEAR,

fin[].qtr= FI_QTR,

fin[].strart_date = FI_QTR_START_DATE,
fin[].rev= FI_REVENUE,

fin[].net_earn= FI_NET_EARN,

fin[].basic_eps= FI_BASIC_EPS,

fin[].dilut_eps= FI_DILUT_EPS,

fin[].margin= FI_MARGIN,

fin[].invent= FI_INVENTORY,

fin[].assets= FI_ASSETS,

fin[].liab= FI_LIABILITY,

fin[].out_basic= FI_OUT_BASIC,

fin[].out_dilut= FI_OUT_DILUT

from
FINANCIAL
where
FI_CO_ID = co_id
order by
FI_YEAR asc,
FI_QTR
fin_len = row_count// Should return max_rows_to_return rows// max_rows_to_return is between 5 and 20
select first max_rows_to_return rows
day[].date= DM_DATE,

day[].close = DM_CLOSE,
day[].high= DM_HIGH,

day[].low= DM_LOW,

day[].vol= DM_VOL

fromDAILY_MARKET
where
DM_S_SYMB = symbol and
DM_DATE >= start_day
order by
DM_DATE asc
day_len = row_countselectlast_price = LT_PRICE,
last_open= LT_OPEN_PRICE,

last_vol= LT_VOLTPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 107 of 287

Security-Detail_Frame-1 Pseudo-code: Get all details about the security
from
LAST_TRADE
where
LT_S_SYMB = symbol// Should return max_news_len (2) rows
if (access_lob_flag)
select first max_news_len rows
news[].item= NI_ITEM,

news[].dts= NI_DTS,

news[].src= NI_SOURCE,

news[].auth= NI_AUTHOR,

news[].headline = “”,news[].summary

= “”

from
NEWS_XREF,
NEWS_ITEM
where
NI_ID = NX_NI_ID and
NX_CO_ID = co_id
else
select first max_news_len rows
news[].item= “”,news[].dts= NI_DTS,

news[].src= NI_SOURCE,

news[].auth= NI_AUTHOR,

news[].headline = NI_HEADLINE,
news[].summary= NI_SUMMARY

from
NEWS_XREF,
NEWS_ITEM
where
NI_ID = NX_NI_ID and
NX_CO_ID = co_id
news_len = row_countcommit transaction

}

3.3.6

The Trade-Lookup Transaction
The Trade-Lookup Transaction is designed to emulate information retrieval by either a customer or abroker to satisfy their questions regarding a set of trades. The various sets of trades are chosen such thatthe work is representative of:

performing general market analysis
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 108 of 287



reviewing trades for a period of time prior to the most recent account statementanalyzing past performance of a particular security

analyzing the history of a particular customer holding

Trade-Lookup is invoked by EGenDriverCE. It consists of four mutually exclusive Frames. Each Frame
employs a different technique for looking up historical trade data.
Frame 1 accepts a list of trade IDs. Information for each of the trades in the list is returned.
Frame 2 accepts a customer account ID, a start timestamp, end timestamp and a number of trades (N)as inputs. It returns information for the first N trades for the specified customer account between thestart and end timestamps (inclusive).
Frame 3 accepts a security symbol, a start timestamp, end timestamp and a number of trades (N) as
inputs. It returns information for the first N trades for the given security between the start and end
timestamps (inclusive).
Frame 4 accepts a customer account ID and a timestamp as inputs. The first trade for this customer
account at or after the specified timestamp is identified. Then a maximum of 20 historical holding
changes for this trade ID are returned. The historical holding changes report on changes made by thistrade to holdings created by prior trades, and report on changes made by subsequent trades to any
holding created by this trade.
3.3.6.1

Trade-Lookup Transaction Parameters

The inputs to the Trade-Lookup Transaction are generated by the EGenDriverCE code in
CETxnInputGenerator.cpp. The data structures defined in TxnHarnessStructs.h must be used tocommunicate the input and output parameters.
Trade-Lookup Interfaces

Module/Data Structure

CE Input generation

GenerateTradeLookupInput()

Transaction Input/Output
Structure

TTradeLookupTxnInput
TTradeLookupTxnOutput

Frame 1 Input/Output Structure

TTradeLookupFrame1Input
TTradeLookupFrame1Output

Frame 2 Input/Output Structure

TTradeLookupFrame2Input
TTradeLookupFrame2Output

Frame 3 Input/Output Structure

TTradeLookupFrame3Input
TTradeLookupFrame3Output

Frame 4 Input/Output Structure

TTradeLookupFrame4Input
TTradeLookupFrame4Output

Trade-Lookup Transaction Parameters:
Parameter

Direction

Description

acct_idIN

Customer account ID. Used when frame_to_execute is 2 or 4, otherwise set to0.
For Frames 1 and 4, this parameter is ignored, so it is set to an empty date.

end_trade_dts

IN

Used in Frame 2 as the end point in time for identifying a particular trade.
Used in Frame 3 as the end point in time for identifying trades for a particularsymbol.

frame_to_execute

IN

Identifies which of the mutually exclusive frames to execute.

max_acct_id

INUsed in Frame 3 to identify the maximum customer account ID, otherwise set
to 0.

max_trades

IN

Used in Frames 1, 2 and 3 for the number of trades to find otherwise set to 0.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 109 of 287

The default value for max_trades for each frame is set in the
TTradeLookupSettings structure in DriverParameterSettings.h
For Frame 1, this parameter is ignored, so it is set to an empty date.

3.3.6.2

Used in Frame 2 as the point in time for identifying a particular trade.
Non-uniform over pre-populated interval.
Used in Frame 3 as the point in time for identifying trades for a particularsymbol.
Uniform over pre-populated interval.
Used in Frame 4 as the point in time for identifying a particular trade.
Uniform over pre-populated interval.

start_trade_dts

INsymbolIN

Used in Frame 3 as the security symbol for which to find trades. Uniformly
chosen over all securities. For the other frames symbol is set to the empty
string.

trade_id[ ]IN

Array of non-uniform randomly chosen trade IDs used by Frame 1 to identify
a set of particular trades. For the other frames array elements are set to 0. For
Frame 1, max_trades indicates how many elements are to be used in the array.

frame_executed

OUT

Confirmation of which frame was executed.

is_cash[ ]OUT

Indicates whether the trades used in Frame 1, 2 or 3 were cash transactions.

is_market[ ]OUT

Indicates whether the trades used in Frame 1 were market order trades.

num_found

OUT

Number of trade rows found for frames 1, 2, 3, or number of holding history
rows found for frame 4.

statusOUT

Code indicating the execution status for this transaction.

trade_list[ ]OUT

List of trade IDs found in Frames 2 and 3.

Trade-Lookup Transaction Database Footprint

The Trade-Lookup Database Footprint is as follows:
Trade-Lookup Database Footprint
Frame
Table

CASH_TRANSACTIONHOLDING_HISTORY

Column1*2*3*

CT_AMT

Return*Return*Return*CT_DTS

Return*Return*Return*CT_NAME

Return*Return*Return*Row(s)
SE_AMTSETTLEMENT

Return*ReturnReturnReturnSE_CASH_DUE_DATE Return

ReturnReturnSE_CASH_TYPE

ReturnReturnReturnT_BID_PRICE

ReturnReturn

T_CA_ID

Return

T_DTS
T_EXEC_NAME
TRADE

Reference Return
Return

T_ID
T_IS_CASH

ReturnReturnReturnReturnReturnReturnReturnT_QTY

Return

T_S_SYMB

Reference

T_TRADE_PRICE

4*ReturnReturnReference

ReturnReturnTPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 110 of 287

T_TT_ID
TRADE_HISTORY
TRADE_TYPE

ReturnTH_DTS

ReturnReturnReturn

TH_ST_ID

ReturnReturnReturnTT_IS_MRKTReturnStart
StartCommit Commit

StartCommitTransaction Control

3.3.6.3

Start
CommitTrade-Lookup Transaction Frame 1 of 4

The first Frame is responsible for retrieving information about the specified array of trade IDs.
The EGenTxnHarness controls the execution of Frame 1 as follows:{if( frame_to_execute == 1 ){invoke (Trade-Lookup_Frame-1)
if (num_found != max_trades) then{status = -611}
frame_executed = 1}[...]
Trade-Lookup Frame 1 of 4 Parameters:
Parameter

Direction

Description

max_tradesIN

Number of valid array elements in trade_id[ ]. The default value (20) is
set in TTradeLookupSettings.MaxRowsFrame1 in
DriverParameterSettings.h.

trade_id[ ]INThe array of trade IDs picked non-uniformly over the set of prepopulated trades.

bid_price[ ]OUTThe requested unit price.

cash_transaction_amount[ ]OUT

Amount of the cash transaction.

cash_transaction_dts[ ]OUT

Date and time stamp of when the transaction took place.

cash_transaction_name[ ]OUT

Description of the cash transaction.

exec_name[ ]OUTName of the person who executed the trade.

is_cash[ ]OUT

Flag that is non-zero for a cash trade, zero for a margin trade.

is_market[ ]OUT

Flag that is non-zero for a market trade, zero for a limit trade.

num_found

OUT

Number of trade rows returned; should be the same as max_trades.

settlement_amount[ ]OUT

Cash amount of settlement.

settlement_cash_due_date[ ]OUT

Date by which customer or brokerage must receive the cash.

settlement_cash_type[ ]OUT

Type of cash settlement involved: cash or margin.

trade_history_dts[ ][3]OUT

Array of timestamps of when the trade history was updated.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 111 of 287

trade_history_status_id[ ][3]OUT

Array of status type identifiers.

trade_price[ ]OUT

Unit price at which the security was traded.

Trade-Lookup_Frame-1 Pseudo-code: Get trade information for each trade ID in
the trade_id array{declare i int
start transaction
num_found = 0
for (i = 0; i++; i < max_trades) do {// Get trade information// Should only return one row for each trade
selectbid_price[i]= T_BID_PRICE,

exec_name[i]= T_EXEC_NAME,

is_cash[i]= T_IS_CASH,

is_market[i]= TT_IS_MRKT,

trade_price[i] = T_TRADE_PRICE
fromTRADE,TRADE_TYPE
where
T_ID = trade_id[i] andT_TT_ID = TT_ID
num_found = num_found + row_count// Get settlement information// Should only return one row for each trade
selectsettlement_amount[i]= SE_AMT,

settlement_cash_due_date[i] = SE_CASH_DUE_DATE,
settlement_cash_type[i]= SE_CASH_TYPE

from
SETTLEMENT
where
SE_T_ID = trade_id[i]// get cash information if this is a cash transaction// Should only return one row for each trade that was a cash transaction
if (is_cash[i]) then {selectcash_transaction_amount[i] = CT_AMT,TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 112 of 287

Trade-Lookup_Frame-1 Pseudo-code: Get trade information for each trade ID in
the trade_id arraycash_transaction_dts[i]= CT_DTS,

cash_transaction_name[i]= CT_NAME

from
CASH_TRANSACTION
where
CT_T_ID = trade_id[i]}// read trade_history for the trades// Should return 2 to 3 rows per trade
select first 3 rows
trade_history_dts[i][]= TH_DTS,

trade_history_status_id[i][] = TH_ST_ID
from
TRADE_HISTORY
where
TH_T_ID = trade_id[i]order by
TH_DTS} // end for loop
commit transaction}

3.3.6.4

Trade-Lookup Transaction Frame 2 of 4

The second Frame returns information for the first N trades executed for the specified customer
account between a specified start time and end time. If the specified start time is too close to thespecified end time, then it is possible that fewer than N trades may be returned.
The EGenTxnHarness controls the execution of Frame 2 as follows:

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 113 of 287

[...]
else if( frame_to_execute == 2 ){invoke (Trade-Lookup_Frame-2)
if (num_found < 0) or (num_found > max_trades) then{status = -621}
else if (num_found == 0) then{// Can happen rarely in large databases when an account has no trades// in the last 4 days
status = +621}
frame_executed = 2}[...]
Trade-Lookup Frame 2 of 4 Parameters:
Parameter

Direction

Description

acct_idIN

A single customer is chosen non-uniformly by customer tier, fromthe range of available customers. The rules for determining therange of available customers are described in clause 3.2.2.1. A single
customer account id, as defined by CA_ID in
CUSTOMER_ACCOUNT, is chosen at random, uniformly, from therange of customer account ids for the chosen customer.

end_trade_dts

IN

Point in time at which to stop searching for N trades.

max_tradesIN

Maximum number of trades to return. The default value (20) is set
in TTradeLookupSettings.MaxRowsFrame2 in
DriverParameterSettings.h.

start_trade_dts

IN

Point in time from which to search for N trades.

bid_price[ ]OUTThe requested unit price.

cash_transaction_amount[ ]OUT

Amount of the cash transaction.

cash_transaction_dts[ ]OUT

Date and time stamp of when the transaction took place.

cash_transaction_name[ ]OUT

Description of the cash transaction.

exec_name[ ]OUTName of the person who executed the trade.

is_cash[ ]OUT

Flag that is non-zero for a cash trade, zero for a margin trade.

num_found

OUT

Number of trade rows returned (may be less than max_trades).

settlement_amount[ ]OUT

Cash amount of settlement.

settlement_cash_due_date[ ]OUT

Date by which customer or brokerage must receive the cash.

settlement_cash_type[ ]OUT

Type of cash settlement involved: cash or margin.

trade_history_dts[ ][3]OUT

Array of timestamps of when the trade history was updated.

trade_history_status_id[ ][3]OUT

Array of status type identifiers.

trade_list[ ]OUT

Trade ID actually used for retrieving data.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 114 of 287

trade_price[ ]OUT

Unit price at which the security was traded.

Trade-Lookup_Frame-2 Pseudo-code : Get trade information for the first N
trades of a given customer account from a given point in time.

{
declare i int
start transaction// Get trade information// Should return between 0 and max_trades rows
select first max_trades rows
bid_price[]= T_BID_PRICE,

exec_name[]= T_EXEC_NAME,

is_cash[]= T_IS_CASH,

trade_list[]= T_ID,

trade_price[] = T_TRADE_PRICE
from
TRADE
where
T_CA_ID = acct_id and
T_DTS >= start_trade_dts and
T_DTS <= end_trade_dts
order by
T_DTS asc
num_found= row_count// Get extra information for each trade in the trade list.
for (i = 0; i < num_found; i++) {// Get settlement information// Should return only one row for each trade
selectsettlement_amount[i]= SE_AMT,

settlement_cash_due_date[i] = SE_CASH_DUE_DATE,
settlement_cash_type[i]= SE_CASH_TYPE

from
SETTLEMENT
where
SE_T_ID = trade_list[i]// get cash information if this is a cash transaction// Should return only one row for each trade that was a cash transaction
if (is_cash[i]) then {selectcash_transaction_amount[i] = CT_AMT,TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 115 of 287

Trade-Lookup_Frame-2 Pseudo-code : Get trade information for the first N
trades of a given customer account from a given point in time.
cash_transaction_dts[i]= CT_DTS

cash_transaction_name[i]= CT_NAME

from
CASH_TRANSACTION
where
CT_T_ID = trade_list[i]}// read trade_history for the trades// Should return 2 to 3 rows per trade
select first 3 rows
trade_history_dts[i][]= TH_DTS,

trade_history_status_id[i][] = TH_ST_ID
from
TRADE_HISTORY
where
TH_T_ID = trade_list[i]order by
TH_DTS} // end for loop
commit transaction}

3.3.6.5

Trade-Lookup Transaction Frame 3 of 4

The third Frame returns information for the first N trades for a given security between a specified start
time and end time. If the specified start time is too close to the specified end time, then it is possible thatfewer than N trades may be returned.
The EGenTxnHarness controls the execution of Frame 3 as follows:

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 116 of 287

[...]
else if( frame_to_execute == 3 ){invoke (Trade-Lookup_Frame-3)
if (num_found < 0) or (num_found > max_trades) then{status = -631}
else if (num_found == 0) then{// Can happen rarely in large databases
status = +631}
frame_executed = 3}}
Trade-Lookup Frame 3 of 4 Parameters:
Parameter

Direction

Description

end_trade_dts

IN

Point in time at which to end the search.

max_acct_id

INMaximum customer account ID.

max_tradesIN

Maximum number of trades to find. The default value (20) is set in
TTradeLookupSettings.MaxRowsFrame3 in
DriverParameterSettings.h.

start_trade_dts

IN

Point in time from which to start search.

symbolIN

Security for which to find trades.

acct_id[ ]OUT

Array of accounts for which the trades were done.

cash_transaction_amount[ ]OUT

Amount of the cash transaction.

cash_transaction_dts[ ]OUT

Date and time stamp of when the transaction took place.

cash_transaction_name[ ]OUT

Description of the cash transaction.

exec_name[ ]OUTArray of name of the person who executed each of the trades.

is_cash[ ]OUT

Flag that is non-zero for a cash trade, zero for a margin trade.

num_found

OUT

Number of TRADE rows returned.

price[ ]OUTArray of the price that was paid in each trade.

quantity[ ]OUTArray of the quantity of security bought in each trade.

settlement_amount[ ]OUT

Cash amount of settlement.

settlement_cash_due_date[ ]OUT

Date by which the customer or brokerage must receive the cash.

settlement_cash_type[ ]OUT

Type of cash settlement involved: cash or margin.

trade_dts[ ]OUTArray of the timestamps for when the trade was requested.

trade_history_dts[ ][3]OUT

Array of timestamps of when the trade history was updated.

trade_history_status_id[ ][3]OUT

Array of status type identifiers.

trade_list[ ]OUTArray of T_IDs found.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 117 of 287

trade_type[ ]OUTArray of the trade type for each trade.

Trade-Lookup_Frame-3 Pseudo-code: Get a list of N trades executed for acertain security starting from a given point in time.

{
declare i int
start transaction// Should return between 0 and max_trades rows.
select first max_trades rows
acct_id[]= T_CA_ID,

exec_name[]= T_EXEC_NAME,

is_cash[]= T_IS_CASH,

price[]= T_TRADE_PRICE,

quantity[]= T_QTY,

trade_dts[]= T_DTS,

trade_list[] = T_ID,
trade_type[] = T_TT_ID
from
TRADE
where
T_S_SYMB = symbol and
T_DTS >= start_trade_dts and
T_DTS <= end_trade_dts// The max_acct_id “where” clause is a hook used for engineering purposes// only and is not required for benchmark publication purposes.
// T_CA_ID <= max_acct_id
order by
T_DTS asc
num_found = row_count// Get extra information for each trade in the trade list.
for (i = 0; i < num_found; i++) {// Get settlement information// Should return only one row for each trade
selectsettlement_amount[i]= SE_AMT,

settlement_cash_due_date[i] = SE_CASH_DUE_DATE,
settlement_cash_type[i]= SE_CASH_TYPE

from
SETTLEMENT
where
SE_T_ID = trade_list[i]TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 118 of 287

Trade-Lookup_Frame-3 Pseudo-code: Get a list of N trades executed for acertain security starting from a given point in time.
// get cash information if this is a cash transaction// Should return only one row for each trade that was a cash transaction
if (is_cash[i]) then {selectcash_transaction_amount[i] = CT_AMT,
cash_transaction_dts[i]= CT_DTS

cash_transaction_name[i]= CT_NAME

from
CASH_TRANSACTION
where
CT_T_ID = trade_list[i]}// read trade_history for the trades// Should return 2 to 3 rows per trade
select first 3 rows
trade_history_dts[i][]= TH_DTS,

trade_history_status_id[i][] = TH_ST_ID
from
TRADE_HISTORY
where
TH_T_ID = trade_list[i]order by
TH_DTS asc} // end for loop
commit transaction}

3.3.6.6

Trade-Lookup Transaction Frame 4 of 4

The fourth Frame identifies the first trade for the specified customer account on or after the specified
time. Up to the first 20 rows in the HOLDING_HISTORY with a matching trade ID are then returned. If
the specified time is too close to the end of the historical trade data, it is possible that no matching trade
may be found for the specified customer account.
The EGenTxnHarness controls the execution of Frame 4 as follows:

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 119 of 287

[...]
else if( frame_to_execute == 4 ){invoke (Trade-Lookup_Frame-4)

if (num_trades_found == 0) then{status = +641}

else if (num_trades_found <> 1) then{status = -641}

else if (num_found < 1) or (num_found > 20) then{status = -642}

frame_executed = 4}[...]
Trade-Lookup Frame 4 of 4 Parameters:
Parameter

Direction

Description

acct_idIN

A single customer is chosen non-uniformly by customer tier, fromthe range of available customers. The rules for determining therange of available customers are described in clause 3.2.2.1. A single
customer account id, as defined by CA_ID in
CUSTOMER_ACCOUNT, is chosen at random, uniformly, from therange of customer account ids for the chosen customer.

start_trade_dts

IN

Point in time from which to search for a trade.

holding_history_id[20]

OUT

Array of trade identifiers of the trades that originally created each of
the returned holding rows.

holding_history_trade_id[20]

OUT

Array of trade identifiers of the trades that modified each of the
returned holding rows.

num_found

OUT

Number of HOLDING_HISTORY rows returned (may be zero).

num_trades_found

OUT

Number of TRADE rows found.

quantity_after[20]

OUT

Array of quantities of the security that was held after the holding
was modified.

quantity_before[20]

OUT

Array of quantities of the security that was held before the holding

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 120 of 287

was modified.
trade_id

OUT

ID of first trade found for customer account at or after the specified
time. This is the ID that is used for the look up in
HOLDING_HISTORY.

Trade-Lookup_Frame-4 Pseudo-code: Return HOLDING_HISTORY information for aparticular trade ID.

{
start transaction
select first 1 row
trade_id = T_ID
from
TRADE
where
T_CA_ID = acct_id and
T_DTS >= start_trade_dts
order by
T_DTS asc
num_trades_found = row_count// The trade_id is used in the subquery to find the original trade_id// (HH_H_T_ID), which then is used to list all the entries.
// Should return 0 to (capped) 20 rows.
select first 20 rows
holding_history_id[]= HH_H_T_ID,

holding_history_trade_id[] = HH_T_ID,
quantity_before[]= HH_BEFORE_QTY,

quantity_after[]= HH_AFTER_QTY

fromHOLDING_HISTORY
where
HH_H_T_ID in(select
HH_H_T_ID
from
HOLDING_HISTORY
where
HH_T_ID = trade_id)
num_found = row_countcommit transaction}

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 121 of 287

Trade-Lookup_Frame-4 Pseudo-code: Return HOLDING_HISTORY information for aparticular trade ID.

3.3.7

The Trade-Order Transaction
The Trade Order Transaction is designed to emulate the process of buying or selling a security by a
Customer, Broker, or authorized third-party. If the person executing the trade order is not the accountowner, the Transaction will verify that the person has the appropriate authorization to perform thetrade order. The Transaction allows the person trading to execute buys at the current market price,sells at the current market price, or limit buys and sells at a requested price. The Transaction also
provides an estimate of the financial impact of the proposed trade by providing profit/loss data, tax
implications, and anticipated commission fees. This allows the trader to evaluate the desirability of the
proposed security trade before either submitting or canceling the trade.
The Trade-Order Transaction is invoked by EGenDriverCE. It consists of six Frames. The Transaction
starts by using the account ID passed into the Transaction to obtain information on the customer, thecustomer’s account, and the broker for the account.
Next, the Transaction conditionally validates that the person executing the trade is authorized toperform such actions on the specified account. If the executor is not authorized, then the Transactionrolls back. However, during the benchmark execution, the CE will always generate authorized
executors.
The next step is to estimate the overall financial implications of executing the trade. For limit-orders,
the requested price is used in the estimation; for market orders, the requested price is set to the current
market value of the security and that value is used in the estimation. Estimation includes assessing any
effects the requested trade would have on existing holdings (e.g. the sale of existing long positions, orthe cover of existing short positions). If a profit would be realized as a result of this trade, the capitalgains taxes are calculated. Administrative fees and the broker’s commission for handling the trade arecalculated. If the trade is being submitted on margin, the customer’s total assets for the account areassessed. All the above information is used for recording the order.
After all the above processing has completed, a small percentage of the Trade-Order Transactions are
selected to emulate either the canceling the order or an error condition by rolling back all modifications.
All other Trade-Order Transactions are Committed. After a successfully Committed market order, the
EGenTxnHarness sends the order for the trade to the appropriate MEE.

3.3.7.1

Trade-Order Transaction Parameters

The inputs to the Trade-Order Transaction are generated by the EGenDriverCE code in
CETxnInputGenerator.cpp. The data structures defined in TxnHarnessStructs.h must be used tocommunicate the input and output parameters.
Trade-Order Interfaces

Module/Data Structure

CE Input generation

GenerateTradeOrderInput()

Transaction Input/Output Structure

TTradeOrderTxnInput
TTradeOrderTxnOutput

Frame 1 Input/Output Structure

TTradeOrderFrame1Input
TTradeOrderFrame1Output

Frame 2 Input/Output Structure

TTradeOrderFrame2Input
TTradeOrderFrame2Output

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 122 of 287

Frame 3 Input/Output Structure

TTradeOrderFrame3Input
TTradeOrderFrame3Output

Frame 4 Input/Output Structure

TTradeOrderFrame4Input
TTradeOrderFrame4Output

Frame 5 Input/Output Structure<none>

Frame 6 Input/Output Structure<none>

Trade-Order Transaction Parameters:
Parameter

Direction

DescriptionIN

A single customer is chosen non-uniformly by customer tier, from the range ofavailable customers. The rules for determining the range of available customers aredescribed in clause 3.2.2.1. A single customer account id, as defined by CA_ID in
CUSTOMER_ACCOUNT, is chosen at random, uniformly, from the range ofcustomer account ids for the chosen customer.

IN

The security being traded in this transaction can be specified in one of two ways.
Either by specifying the security’s symbol, or by specifying the company name andthe issue. If the symbol is used to specify the security, then the company name andthe issue are an empty string (i.e. “”). Otherwise the company name and the issue
are both specified and the symbol is an empty string (i.e. “”). For more information,
see Clause 6.4.1.

INFirst name of the person executing the trade. Note that the person executing thistrade, may not be the registered owner of the account. If this is the case, theexecutor’s permission to execute trades for this account will be verified in Frame 2.
For more information, see Clause 6.4.1.

exec_l_nameIN

Last name of the person executing the trade. Note that the person executing thistrade, may not be the registered owner of the account. If this is the case, theexecutor’s permission to execute trades for this account will be verified in Frame 2.
For more information, see Clause 6.4.1.

exec_tax_id

IN

Tax identifier for the person executing the trade. Note that the person executing thistrade, may not be the registered owner of the account. If this is the case, theexecutor’s permission to execute trades for this account will be verified in Frame 2.
For more information, see Clause 6.4.1.

is_lifoIN

If this flag is set to 1 then this trade will process against existing holdings fromnewest to oldest (LIFO order). If this flag is set to 0, then this trade will processagainst existing holdings from oldest to newest (FIFO order).

issue

IN

The security being traded in this transaction can be specified in one of two ways.
Either by specifying the security’s symbol, or by specifying the company name andthe issue. If the symbol is used to specify the security, then the company name andthe issue are an empty string (i.e. “”). Otherwise the company name and the issue
are both specified and the symbol is an empty string (i.e. “”). For more information,
see Clause 6.4.1.

requested_priceIN

For a limit order, this is the requested price for triggering the trade. For a market
order, the input value is undefined and this variable is set to the current market
price for the given security inside Frame 3.

roll_it_backIN

If this flag is 1 then an intentional rollback (Frame 5) is executed. If 0, then a commit(Frame 6) is executed. See Clause 6.4.1 for details on the percentage of trades thatwill be intentionally rolled back.

st_pending_id

IN

Identifier for the “Pending” order status – passed in for ease of benchmarking.

st_submitted_id

IN

Identifier for the “Submitted” order status – passed in for ease of benchmarking.

IN

The security being traded in this transaction can be specified in one of two ways.
Either by specifying the security’s symbol, or by specifying the company name andthe issue. If the symbol is used to specify the security, then the company name andthe issue are an empty string (i.e. “”). Otherwise the company name and the issue
are both specified and the symbol is an empty string (i.e. “”). For more information,
see Clause 6.4.1.

acct_idco_nameexec_f_namesymbolTPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 123 of 287

3.3.7.2

trade_qty

IN

The number of shares to be traded for this order.

trade_type_id

IN

Identifier indicating the type of trade - passed in for each of benchmarking. For more
information on the different types of trades generated, see Clause 6.4.1.

type_is_marginIN

If this flag is set to 1, then the order will be done on margin. If the flag is set to 0,
then this trade will be done with cash.

buy_value

OUT

The total dollar amount for the securities bought for a matching sell order. If trade
is a buy or sell of new securities then buy_value is zero.

sell_value

OUT

The total dollar value of the securities sold for a matching buy order. If trade is buy
or sell of new securities then sell_value is zero.

statusOUT

Code indicating the execution status for this transaction.

tax_amount

OUT

The estimated amount of tax that will be incurred as a result of this order. If no
profit is realized, then tax_amount is zero.

trade_id

OUT

Unique trade identifier generated by the SUT for this order.

Trade-Order Transaction Database Footprint

This Transaction includes a mixture of Add, Reference, and Return access methods. The Trade-Order
Database Footprint is as follows:
Trade-Order Database Footprint
Frame
Table

Column1

ACCOUNT_PERMISSION

2*

AP_ACL

ReturnAP_CA_ID

Reference

AP_F_NAME

Reference

AP_L_NAME

Reference

AP_TAX_ID

Reference

3

BROKER

B_NAMECHARGE

CH_CHRG

ReturnCOMMISSION_RATE

CR_RATE

ReturnCO_ID

Reference*

CO_NAME

Return*COMPANYCUSTOMERCUSTOMER_TAXRATEHOLDING

5*

ReturnC_F_NAME

ReturnC_L_NAME

ReturnC_TIER

ReturnC_TAX_ID

ReturnCA_BALCUSTOMER_ACCOUNT

4

Reference*

CA_B_ID

ReturnCA_C_ID

ReturnCA_NAME

ReturnCA_TAX_ST

ReturnCX_TX_ID

Reference*

H_PRICE

Reference

H_QTY

Reference

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 124 of 287

6*

HOLDING_SUMMARY

HS_QTY

Reference

LAST_TRADE

LT_PRICE

Return

S_CO_ID

Reference*

S_EX_ID

Reference

S_NAME

ReturnS_SYMB

Return*TAXRATETX_RATE

Reference*

TRADE

1 Row

Add

TRADE_HISTORY

1 Row

Add

TRADE_REQUEST

1 Row

Add*

SECURITY

TRADE_TYPE

TT_IS_MRKTReturnTT_IS_SELL

ReturnStart

Transaction Control

3.3.7.3

Rollback

CommitTrade-Order Transaction Frame 1 of 6

The first Frame is responsible for retrieving information about the customer, customer account, and its
broker.
The EGenTxnHarness controls the execution of Frame 1 as follows:{
invoke (Trade-Order_Frame-1)
if (num_found <> 1) then{status = -711}}
Trade-Order Frame 1 of 6 Parameters:
Parameter

Direction

Description

acct_idIN

Identifier of the customer account involved in the transaction.

acct_nameOUTName of the account specified by acct_id.

broker_id

OUT

Identifier of the broker associated with the specified acct_id.

broker_name

OUT

Name of the broker associated with the specified acct_id.

cust_f_name

OUTFirst name of the customer who owns the specified account. This output string
must not contain trailing white space.

cust_id

OUT

Unique identifier of the customer who owns the specified account.

cust_l_name

OUT

Last name of the customer who owns the specified account. This output string
must not contain trailing white space.

cust_tier

OUT

The brokerage house service level tier this customer belongs to.

num_found

OUT

Number of CUSTOMER_ACCOUNT rows found.

tax_idOUT

Tax identifier for the customer who owns the specified account. This output
string must not contain trailing white space.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 125 of 287

tax_status

OUT

Tax status of the customer who owns the specified account.

Trade-Order_Frame-1 Pseudo-code: Get customer, customer account, and broker
information{
start transation// Get account, customer, and broker information
selectacct_name= CA_NAME,

broker_id= CA_B_ID,

cust_id= CA_C_ID,

tax_status = CA_TAX_ST
from
CUSTOMER_ACCOUNT
where
CA_ID = acct_id
num_found = row_countselectcust_f_name = C_F_NAME,
cust_l_name = C_L_NAME,
cust_tier= C_TIER,

tax_id= C_TAX_ID

from
CUSTOMER
where
C_ID = cust_id
selectbroker_name = B_NAME
fromBROKER
where
B_ID = broker_id}

3.3.7.4

Trade-Order Transaction Frame 2 of 6

The second Frame is conditionally executed when the Transaction executor’s first name, last name, andtax id do not match the customer first name, customer last name, and customer tax id returned in
Frame 1. Frame 2 is responsible for validating the executor’s permission to order trades for the
specified customer account.
The database access methods used in Frame 2 are all References.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 126 of 287

{
if (exec_l_name != cust_l_name orexec_f_name != cust_f_name orexec_tax_id != tax_id) then{invoke (Trade-Order_Frame-2)
if (ap_acl[0] == ‘\0’) then{status = -721;}}}
Trade-Order Frame 2 of 6 Parameters:
Parameter

Direction

Description

acct_idIN

Identifier of the customer account involved in the transaction.

exec_f_name

IN

First name of the person executing the trade.

exec_l_nameIN

Last name of the person executing the trade.

exec_tax_id

IN

Tax identifier for the person executing the trade.

ap_aclOUT

Account permission access control list string for this executor on this customer
account. If a NULL string is returned, then the executor of this transaction does
not have permission to execute trades for the specified account.

Trade-Order_Frame-2 Pseudo-code : Check executor's permission{
selectap_acl = AP_ACL
fromACCOUNT_PERMISSION
where
AP_CA_ID = acct_id and
AP_F_NAME = exec_f_name and
AP_L_NAME = exec_l_name and
AP_TAX_ID = exec_tax_id}

3.3.7.5

Trade-Order Transaction Frame 3 of 6

The third Frame is responsible for estimating the overall impact of executing the requested trade. Profit
and loss estimates are calculated and capital gains taxes are estimated based on any profits.
Administrative fees and commission rates are obtained. If this is a margin trade, the customer’s assets
needed to cover the cost of the trade are calculated using current market values.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 127 of 287

The database access methods used in Frame 3 are References and Returns.
The EGenTxnHarness controls the execution of Frame 3 as follows:{
invoke (Trade-Order_Frame-3)
if ((sell_value > buy_value) and((tax_status == 1) or (tax_status == 2)) and(tax_amount <= 0.00)) then{status = -731}
else if (comm_rate <= 0.0000) then{status = -732}
else if (charge_amount == 0.00) then{status = -733}}
Trade-Order Frame 3 of 6 Parameters:
Parameter

Direction

Description

acct_idIN

Identifier of the customer account involved in the transaction.

cust_idIN

Unique identifier of the customer who owns the specified account.

cust_tierIN

The brokerage house service level tier this customer belongs to.

is_lifoIN

If this flag is set to 1 then this trade will process against existing holdings
from newest to oldest (LIFO order). If this flag is set to 0, then this trade willprocess against existing holdings from oldest to newest (FIFO order).

issue

IN

Specifies the particular issue of security for the given company. This value isan empty string (i.e. “”) if the security is specified by symbol.

st_pending_id

IN

Identifier for the “Pending” order status – passed in for ease ofbenchmarking.

st_submitted_id

IN

Identifier for the “Submitted” order status – passed in for ease ofbenchmarking.

tax_statusIN

Tax status of the customer who owns the specified account.

trade_qty

IN

The number of shares to be traded for this order.

trade_type_id

IN

Identifier indicating the type of trade - passed in for ease of benchmarking.

type_is_marginIN

If this flag is set to 1, then the order will be done on margin. If the flag is set
to 0, then this trade will be done with cash.

IN-OUT

Name of the company for the security being traded. Otherwise, if the trade
is being done based on symbol, then co_name is an empty string (i.e. “”) andwill be set appropriately inside the frame. This output string must notcontain trailing white space.

co_name

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 128 of 287

IN-OUT

For a limit order, this is the requested price for triggering the trade. For amarket order, the input value is undefined and this variable must be set tothe current market price for the given security.

symbolIN-OUT

The stock symbol for the security being traded. Otherwise, if the trade isbeing done based on co_name and issue, then symbol is an empty string (i.e.
“”) and will be set appropriately inside the frame. This output string must
not contain trailing white space.

buy_value

OUT

The total dollar amount for the securities bought for a matching sell order.
If trade is a buy or sell of new securities then buy_value is zero.

charge_amount

OUT

The fee charged by the brokerage house for processing this trade.

comm_rate

OUT

The broker’s commission rate for processing this trade.

acct_assets

OUT

If this trade is being done on margin, this will be set to the sum of the cash
balance and the current market value of all holdings in the specified
account.

market_price

OUT

The current market trading price of the security.

s_nameOUT

The full name of the security. This output string must not contain trailingwhite space.

sell_value

OUT

The total dollar value of the securities sold for a matching buy order. If
trade is buy or sell of new securities then sell_value is zero.

status_id

OUT

Identifier indicating the status of this order (either pending or submitted).
This output string must not contain trailing white space.

tax_amount

OUT

The estimated amount of tax that will be incurred as a result of this order. If
no profit is realized, then tax_amount is zero.

type_is_market

OUT

Flag set to 1 for market orders and to 0 for limit orders.

type_is_sell

OUT

Flag set to 1 for sell orders and to 0 for buy orders.

requested_price

Trade-Order_Frame-3 Pseudo-code: Estimate overall effects of the trade{
Declare co_id

IDENT_T

Declare exch_id

CHAR(6)// Get information on the security
if (symbol == “”) then {selectco_id = CO_ID
from
COMPANY
where
CO_NAME = co_nameselectexch_id = S_EX_ID,
s_name= S_NAME,

symbol= S_SYMBfromTPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 129 of 287

Trade-Order_Frame-3 Pseudo-code: Estimate overall effects of the trade
SECURITY
where
S_CO_ID = co_id and
S_ISSUE = issue} else {selectco_id= S_CO_ID,

exch_id = S_EX_ID,
s_name= S_NAME

fromSECURITY
where
S_SYMB = symbol
selectco_name = CO_NAME
fromCOMPANY
where
CO_ID = co_id}// Get current pricing information for the security
selectmarket_price = LT_PRICEfrom
LAST_TRADE
where
LT_S_SYMB = symbol// Set trade characteristics based on the type of trade.
selecttype_is_market = TT_IS_MRKT,
type_is_sell= TT_IS_SELL

fromTRADE_TYPE
where
TT_ID = trade_type_id// If this is a limit-order, then the requested_price was passed in to the frame,// but if this a market-order, then the requested_price needs to be set to the// current market price.
if( type_is_market ) then {requested_price = market_price}

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 130 of 287

Trade-Order_Frame-3 Pseudo-code: Estimate overall effects of the trade// Local frame variables used when estimating impact of this trade on// any current holdings of the same security.
Declare hold_price S_PRICE_T
Declare hold_qty

S_QTY_T

Declare needed_qty S_QTY_T
Declare hs_qty

S_QTY_T// Initialize variables
buy_value = 0.0
sell_value = 0.0
needed_qty = trade_qty
selecths_qty = HS_QTY
fromHOLDING_SUMMARY
where
HS_CA_ID= acct_id and

HS_S_SYMB = symbol
if (hs_qty is NULL) then// No prior holdings exist – no rows returned

hs_qty = 0
if (type_is_sell) then {// This is a sell transaction, so estimate the impact to any currently held// long postions in the security.
//
if (hs_qty > 0) then {if (is_lifo) then {// Estimates will be based on closing most recently acquired holdings// Could return 0, 1 or many rows
declare hold_list cursor for
select
H_QTY,
H_PRICE
fromHOLDING
where
H_CA_ID = acct_id and
H_S_SYMB = symbol
order by
H_DTS desc
} else {// Estimates will be based on closing oldest holdings// Could return 0, 1 or many rows

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 131 of 287

Trade-Order_Frame-3 Pseudo-code: Estimate overall effects of the tradedeclare hold_list cursor for
select
H_QTY,
H_PRICE
fromHOLDING
where
H_CA_ID = acct_id and
H_S_SYMB = symbol
order by
H_DTS asc}// Estimate, based on the requested price, any profit that may be realized// by selling current holdings for this security. The customer may have// multiple holdings at different prices for this security (representing// multiple purchases different times).
open hold_list
do until (needed_qty = 0 or end_of_hold_list) {fetch from
hold_list
into
hold_qty,
hold_priceif (hold_qty > needed_qty) then {// Only a portion of this holding would be sold as a result of the// trade.
buy_value+= needed_qty * hold_pricesell_value += needed_qty * requested_priceneeded_qty = 0} else {// All of this holding would be sold as a result of this trade.
buy_value+= hold_qty * hold_pricesell_value += hold_qty * requested_priceneeded_qty = needed_qty - hold_qty}}
close hold_list}// NOTE: If needed_qty is still greater than 0 at this point, then the// customer would be liquidating all current holdings for this security, and// then creating a new short position for the remaining balance of// this transaction.
} else {// This is a buy transaction, so estimate the impact to any currently held

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 132 of 287

Trade-Order_Frame-3 Pseudo-code: Estimate overall effects of the trade// short positions in the security. These are represented as negative H_QTY// holdings. Short postions will be covered before opening a long postion in// this security.
if (hs_qty < 0) then {// Existing short position to buy

if (is_lifo) then {// Estimates will be based on closing most recently acquired holdings// Could return 0, 1 or many rows
declare hold_list cursor for
select
H_QTY,
H_PRICE
fromHOLDING
where
H_CA_ID = acct_id and
H_S_SYMB = symbol
order by
H_DTS desc
} else {// Estimates will be based on closing oldest holdings// Could return 0, 1 or many rows
declare hold_list cursor for
select
H_QTY,
H_PRICE
fromHOLDING
where
H_CA_ID = acct_id and
H_S_SYMB = symbol
order by
H_DTS asc}// Estimate, based on the requested price, any profit that may be realized// by covering short postions currently held for this security. The customer// may have multiple holdings at different prices for this security// (representing multiple purchases at different times).
open hold_list
do until (needed_qty = 0 or end_of_hold_list) {fetch from
hold_list
into
hold_qty,
hold_price

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 133 of 287

Trade-Order_Frame-3 Pseudo-code: Estimate overall effects of the tradeif (hold_qty + needed_qty < 0) then {// Only a portion of this holding would be covered (bought back) as// a result of this trade.
sell_value += needed_qty * hold_pricebuy_value+= needed_qty * requested_priceneeded_qty = 0} else {// All of this holding would be covered (bought back) as// a result of this trade.
// NOTE: Local variable hold_qty is made positive for easy// calculations
hold_qty= -hold_qty

sell_value += hold_qty * hold_pricebuy_value+= hold_qty * requested_priceneeded_qty = needed_qty - hold_qty}}
close hold_list}// NOTE: If needed_qty is still greater than 0 at this point, then the// customer would cover all current short positions (if any) for this security,// and then open a new long position for the remaining balance// of this transaction.
}// Estimate any capital gains tax that would be incurred as a result of this// transaction.
tax_amount = 0.0
if ((sell_value > buy_value) and((tax_status == 1) or (tax_status == 2))) then {//// Customers may be subject to more than one tax at different rates.
// Therefore, get the sum of the tax rates that apply to the customer// and estimate the overall amount of tax that would result from this order.
//
Declare tax_rates

S_PRICE_T

selecttax_rates = sum(TX_RATE)fromTAXRATE
where
TX_ID in (selectCX_TX_ID
from
CUSTOMER_TAXRATETPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 134 of 287

Trade-Order_Frame-3 Pseudo-code: Estimate overall effects of the trade
where
CX_C_ID = cust_id)
tax_amount = (sell_value – buy_value) * tax_rates}// Get administrative fees (e.g. trading charge, commision rate)
selectcomm_rate = CR_RATE
fromCOMMISSION_RATE
where
CR_C_TIER = cust_tier and
CR_TT_ID = trade_type_id and
CR_EX_ID = exch_id and
CR_FROM_QTY <= trade_qty and
CR_TO_QTY >= trade_qty
selectcharge_amount = CH_CHRG
fromCHARGE
where
CH_C_TIER = cust_tier and
CH_TT_ID = trade_type_id// Compute assets on margin trades
Declare acct_bal

BALANCE_T

Declare hold_assets S_PRICE_T
acct_assets = 0.0
if (type_is_margin) then {selectacct_bal = CA_BAL
from
CUSTOMER_ACCOUNT
where
CA_ID = acct_id// Should return 0 or 1 row
selecthold_assets = sum(HS_QTY * LT_PRICE)
fromHOLDING_SUMMARY,LAST_TRADE
where
HS_CA_ID = acct_id and
LT_S_SYMB = HS_S_SYMB

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 135 of 287

Trade-Order_Frame-3 Pseudo-code: Estimate overall effects of the tradeif (hold_assets is NULL)/* account currently has no holdings */acct_assets = acct_bal
else
acct_assets = hold_assets + acct_bal}// Set the status for this trade
if (type_is_market then {status_id = st_submitted_id} else {status_id = st_pending_id}}

3.3.7.6

Trade-Order Transaction Frame 4 of 6

The fourth Frame is responsible for creating an audit trail record of the order and assigning a uniquetrade ID to it.
The database access methods used in Frame 4 are all Adds.
{// Estimate the total commision amount for this trade.
comm_amount = (comm_rate / 100) * trade_qty * requested_priceexec_name = exec_f_name + " " + exec_l_nameis_cash = !(type_is_margin)
invoke (Trade-Order_Frame-4){
Trade-Order Frame 4 of 6 Parameters:
Parameter

Direction

Description

acct_idIN

Identifier of the customer account involved in the transaction.

broker_id

IN

Identifier of the broker associated with the customer account involved in thetransaction.

charge_amountIN

The fee charged by the brokerage house for processing this trade.

comm_amountIN

The broker’s commission for processing this trade.

exec_nameINFirst and last name of the person executing this trade.

is_cashIN

If this flag is set to 1, then this trade will be done with cash. If this flag is set to 0,
then this trade will be done on margin.

is_lifoIN

If this flag is set to 1 then this trade will process against existing holdings fromnewest to oldest (LIFO order). If this flag is set to 0, then this trade will processagainst existing holdings from oldest to newest (FIFO order).

requested_priceIN

For a limit trade, this is the requested price for triggering action. For a market
order, this has been set by the harness code to the current market price for the
given security.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 136 of 287

status_id

IN

Identifier indicating the status of this order (either pending or submitted).

symbolIN

The stock symbol for the security being traded.

trade_qty

IN

The number of shares to be traded for this order.

trade_type_id

IN

Identifier indicating the type of trade to be executed.

type_is_market

IN

Flag set to 1 for market orders and to 0 for limit orders.

trade_id

OUT

Unique trade identifier generated by the SUT for this order.

Trade-Order_Frame-4 Pseudo-code: Record the trade request by making all
related updates{// Get the timestamp and unique trade ID for this trade.
Declare now_dts

DATETIME

get_current_dts ( now_dts )get_new_trade_id ( trade_id )// Record trade information in TRADE table.
insert into
TRADE (
T_ID, T_DTS, T_ST_ID, T_TT_ID, T_IS_CASH,
T_S_SYMB, T_QTY, T_BID_PRICE, T_CA_ID, T_EXEC_NAME,
T_TRADE_PRICE, T_CHRG, T_COMM, T_TAX, T_LIFO)
values (trade_id,// T_ID

now_dts,// T_DTS

status_id,// T_ST_ID

trade_type_id,// T_TT_ID

is_cash,// T_IS_CASH

symbol,// T_S_SYMB

trade_qty,// T_QTY

requested_price,// T_BID_PRICE

acct_id,// T_CA_ID

exec_name,// T_EXEC_NAME

NULL,// T_TRADE_PRICE

charge_amount,// T_CHRG

comm_amount// T_COMM

0,// T_TAX

is_lifo// T_LIFO)// Record pending trade information in TRADE_REQUEST table if this trade is a// limit tradeif (!type_is_market) {insert into
TRADE_REQUEST (TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 137 of 287

Trade-Order_Frame-4 Pseudo-code: Record the trade request by making all
related updates
TR_T_ID, TR_TT_ID, TR_S_SYMB,
TR_QTY, TR_BID_PRICE, TR_B_ID)
values (trade_id,// TR_T-ID

trade_type_id,// TR_TT_ID

symbol,// TR_S_SYMB

trade_qty,// TR_QTY

requested_price,// TR_BID_PRICE

broker_id// TR_B_ID)}// Record trade information in TRADE_HISTORY table.
insert into
TRADE_HISTORY (TH_T_ID, TH_DTS, TH_ST_ID)
values (trade_id,// TH_T_ID

now_dts,// TH_DTS

status_id// TH_ST_ID)}

3.3.7.7

Trade-Order Transaction Frame 5 of 6

The fifth Frame is conditionally executed when the parameter roll_it_back is set to 1. This Frame is
responsible for intentionally rolling back all database updates from this Transaction, occasionallyexercising the rollback functionality.
There are no database access methods used in Frame 5. This Frame is only using Transaction control
operations.
The EGenTxnHarness controls the execution of Frame 5 as follows:{
if (roll_it_back) then {invoke (Trade-Order_Frame-5)
exit // Rest of transaction and SendToMarket are skipped}{

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 138 of 287

Trade-Order_Frame-5 Pseudo-code: Rollback database transaction{// Intentional rollback of transaction caused by driver (CE).
rollback transaction}

3.3.7.8

Trade-Order Transaction Frame 6 of 6

The sixth Frame is conditionally executed when parameter roll_it_back is set to 0. This Frame is
responsible for committing all database updates from this Transaction.
There are no database access methods used in Frame 6. This Frame is only using Transaction control
operations.
The EGenTxnHarness controls the execution of Frame 6 as follows:{
invoke (Trade-Order_Frame-6)

if (type_is_market) then {eAction = eMEEProcessOrder}else {
eAction = eMEESetLimitOrderTrigger}// Send the trade to the Market Exchange Emulator (MEE)
SendToMarketFromHarness (requested_price,symbol,trade_id,
trade_qty,
trade_type_id,
eAction)}Trade-Order Frame 6 Pseudo-code: Commit database transaction{

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 139 of 287

Trade-Order Frame 6 Pseudo-code: Commit database transaction
commit transaction

}

3.3.8

The Trade-Result Transaction
The Trade-Result Transaction is designed to emulate the process of completing a stock market trade.
This is representative of a brokerage house receiving from the market exchange the final confirmationand price for the trade. The customer’s holdings are updated to reflect that the trade has completed.
Estimates generated when the trade was ordered for the broker commission and other similar
quantities are replaced with the actual numbers and historical information about the trade is recorded
for later reference.
Trade-Result is invoked by EGenDriverMEE. It consists of six Frames. The Transaction starts by using
the trade ID passed into the Transaction to obtain information about the trade. The information
gathered includes the account ID of the customer account, which is used to lookup additional accountinformation.
Next the customer’s holdings are updated to reflect the completion of the trade. The particular work
done depends on the type of trade (buy or sell), the number of shares involved and the customer’scurrent position (long or short) with respect to the security. When selling shares, current holdings are
liquidated to cover the sale. If the customer does not have enough shares to cover the sale, any
currently held shares are liquidated and a short position is taken for the balance of shares. If thecustomer already has a short position and more shares are sold, then the short position is simply
extended. An analogous situation exists when purchasing shares. Any shares bought will first be used
to cover any existing short position. After that, any shares bought will be used to create or extend along position.
If, when reconciling the trade with the customer’s current holdings, any shares are sold for a profit andthe profit is taxable, the amount of tax due on the profit is calculated.
Next the broker’s commission is calculated and then all information with respect to the trade isrecorded.
Finally, settlement records are entered for the trade and if the trade is not on margin, the customer’s
account balance is update accordingly.

3.3.8.1

Trade-Result Transaction Parameters

The inputs to the Trade-Result Transaction are generated by the EGenDriverMEE code in MEE.cpp.
The data structures defined in TxnHarnessStructs.h must be used to communicate the input and output
parameters.
Trade-Result Interfaces

Module/Data Structure

MEE Input generation

CMEESUTInterface::TradeResult()

Transaction Input/Output Structure

TTradeResultTxnInput
TTradeResultTxnOutput

Frame 1 Input/Output Structure

TTradeResultFrame1Input
TTradeResultFrame1Output

Frame 2 Input/Output Structure

TTradeResultFrame2Input
TTradeResultFrame2Output

Frame 3 Input/Output Structure

TTradeResultFrame3Input
TTradeResultFrame3Output

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 140 of 287

Frame 4 Input/Output Structure

TTradeResultFrame4Input
TTradeResultFrame4Output

Frame 5 Input/Output Structure

TTradeResultFrame5Input<none>

Frame 6 Input/Output Structure

TTradeResultFrame6Input
TTradeResultFrame6Output

Trade-Result Transaction Parameters:

3.3.8.2

Parameter

Direction

Description

trade_id

IN

The Trade ID for the trade to be settled. Trade ID is the primary key of the
TRADE table.

trade_priceIN

The price of the trade.

acct_bal

OUT

Customer account’s cash balance after the trade was completed.

acct_id

OUT

Customer account ID of the customer account involved in Trade-Resulttransaction.

load_unit

OUT

Load Unit number for the customer account involved in the Trade-Resulttransaction.

statusOUT

Code indicating the execution status for this transaction.

Trade-Result Transaction Database Footprint

This Transaction includes a mixture of Reference, Return, Modify, Remove and Add operations. The
Trade-Result Database Footprint is as follows:
Trade-Result Database Footprint
Frame
Table

Column
1

2

3*

4

5

B_COMM_TOTAL

Reference
ModifyB_NUM_TRADES

Reference
ModifyBROKER

CASH_TRANSACTION

1 row

COMMISSION_RATE

CR_RATE

ReturnCUSTOMER

C_TIER

Reference

Add *ReturnReference*
Modify*CA_BALCUSTOMER_ACCOUNTCUSTOMER_TAXRATEHOLDING

6

CA_B_ID

ReturnCA_C_ID

ReturnCA_TAX_ST

ReturnCX_TX_ID

Reference

H_PRICE

Reference

H_QTY

Reference
Modify*row(s)

Remove*

1 row

Add*

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 141 of 287

HS_QTYHOLDING_SUMMARYHOLDING_HISTORYSECURITY

1 row

Remove*

1 row

Add*

Row(s)Add

S_EX_ID

Reference

S_NAME

Reference

SETTLEMENT

1 row

TAXRATETX_RATE

TRADE

Reference Modify*

Add
Reference

T_CA_ID

ReturnT_CHRG

Return

T_COMM

ModifyT_DTS

ModifyT_IS_CASH

ReturnT_LIFO

ReturnT_QTY

Return

T_S_SYMB

Return

T_ST_ID

ModifyT_TAX

ModifyT_TRADE_PRICE
T_TT_ID
TRADE_HISTORY

TRADE_TYPE

Return1 row

Add

TT_IS_MRKTReturnTT_IS_SELL

ReturnTT_NAME

ReturnStart

Transaction Control

3.3.8.3

ModifyCommitTrade-Result Transaction Frame 1 of 6

The first Frame is responsible for retrieving information about the customer and its trade.
The database access methods used in Frame 1 are all Returns.
The EGenTxnHarness controls the execution of Frame 1 as follows:{
invoke (Trade-Result_Frame-1)
if (num_found <> 1) then{status = -811}}
Trade-Result Frame 1 of 6 Parameters:
Parameter

Direction

Description

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 142 of 287

trade_id

IN

The trade ID for the trade to be settled passed to the transaction by the MarketExchange-Emulator.

acct_id

OUT

Customer account ID of the customer account involved in Trade-Resulttransaction.

chargeOUT

Fee charged for placing this trade request.

hs_qtyOUT

Current quantity of shares of the security being traded, that the customer holds
in their account.

is_lifoOUT

If this flag is set to 1, then this trade will process against existing holdings fromnewest to oldest (LIFO order). If this flag is set to 0, then this trade will processagainst existing holdings from oldest to newest (FIFO order).

num_found

OUT

Number of TRADE rows found.

symbolOUT

Seven character identifier of security that is being traded. This output string
must not contain trailing white space.

trade_is_cash

OUT

Boolean indicating trade is for cash (1) or on margin (0).

trade_qty

OUT

Quantity of securities traded

type_id

OUT

Trade type identifier, (T_TT_ID). This output string must not contain trailingwhite space.

type_is_market

OUT

Boolean indicating trade type is a market trade (1) or limit trade (0).

type_is_sell

OUT

Boolean indicating if this is a sell trade (1) or a buy trade (0).

type_name

OUT

Trade type nameTrade-Result_Frame-1 Pseudo-code: Get info on the trade and the customer's
account{
start transaction
selectacct_id= T_CA_ID,

type_id= T_TT_ID,

symbol= T_S_SYMB,

trade_qty= T_QTY,

charge= T_CHRG,

is_lifo= T_LIFO,

trade_is_cash = T_IS_CASH
from
TRADE
where
T_ID = trade_id
num_found = row_countselecttype_name= TT_NAME,

type_is_sell= TT_IS_SELL,

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 143 of 287

Trade-Result_Frame-1 Pseudo-code: Get info on the trade and the customer's
account
type_is_market = TT_IS_MRKT
fromTRADE_TYPE
where
TT_ID = type_id
selecths_qty = HS_QTY
fromHOLDING_SUMMARY
where
HS_CA_ID = acct_id and
HS_S_SYMB = symbol
if (hs_qty is NULL) then// no prior holdings exist

hs_qty = 0}

3.3.8.4

Trade-Result Transaction Frame 2 of 6

The second Frame is responsible for modifying the customer's holdings to reflect the result of a buy or asell trade.
The database access methods used in Frame 2 are a mixture of References, Modifies, Removes and
Adds.
The EGenTxnHarness controls the execution of Frame 2 as follows:{
invoke (Trade-Result_Frame-2)}
Trade-Result Frame 2 of 6 Parameters:
Parameter

Direction

Description

acct_idIN

Customer account ID of the customer account involved in the Trade-Resulttransaction obtained in Frame 1

hs_qtyIN

Current quantity of shares of the security being traded, that the customer
holds in their account.

is_lifoIN

If this flag is set to 1, then this trade will process against existing holdings
from newest to oldest (LIFO order). If this flag is set to 0, then this trade willprocess against holdings from oldest to newest (FIFO order).

symbolIN

Seven character security identifier obtained in Frame 1

trade_idIN

The trade ID for the trade to be settled passed to the transaction by theMarket- Exchange-Emulator. Used for insert(s) into the HOLDING and
HOLDING_HISTORY tables.

trade_priceIN

The price of the trade passed to the Trade-Result Transaction by the Market
Exchange Emulator.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 144 of 287

trade_qty

INQuantity of securities traded obtained form Frame 1

type_is_sell

IN

Boolean obtained in Frame 1 indicating if this is a sell trade (1) or a buy trade(0).

broker_id

OUT

ID of the broker who executed the trade.

buy_value

OUT

The total dollar amount for the securities bought for a matching sell order. If
trade is a buy or sell of new securities then buy_value is zero.

cust_id

OUT

Customer ID of the customer who owns the customer account involved in the
trade.

sell_value

OUT

The total dollar value of the securities sold for a matching buy order. If tradeis buy or sell of new securities then sell_value is zero.

tax_status

OUT

Customer account tax status

trade_dts

OUT

Date and time of trade result generated by the SUT.

Trade-Result_Frame-2 Pseudo-code: Update the customer's holdings for buy orsell{// Local Frame Variables
Declare hold_id

IDENT_T

Declare hold_price S_PRICE_T
Declare hold_qty

S_QTY_T

Declare needed_qty S_QTY_T
get_current_dts ( trade_dts )// Initialize variables
buy_value = 0.0
sell_value = 0.0
needed_qty = trade_qty
selectbroker_id= CA_B_ID,

cust_id= CA_C_ID,

tax_status = CA_TAX_ST
from
CUSTOMER_ACCOUNT
where
CA_ID = acct_id// Determine if sell or buy orderif (type_is_sell) then {if (hs_qty == 0) then// no prior holdings exist, but one will be inserted

insert into
HOLDING_SUMMARY (HS_CA_ID,

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 145 of 287

Trade-Result_Frame-2 Pseudo-code: Update the customer's holdings for buy orsell
HS_S_SYMB,
HS_QTY)values (acct_id,
symbol,-trade_qty)
else
if (hs_qty != trade_qty) thenupdateHOLDING_SUMMARY
set
HS_QTY = hs_qty – trade_qty
where
HS_CA_ID = acct_id and
HS_S_SYMB = symbol// Sell Trade:// First look for existing holdings, H_QTY > 0
if (hs_qty > 0) {if (is_lifo) then {// Could return 0, 1 or many rows
declare hold_list cursor for
select
H_T_ID,
H_QTY,
H_PRICE
fromHOLDING
where
H_CA_ID = acct_id and
H_S_SYMB = symbol
order by
H_DTS desc
} else {// Could return 0, 1 or many rows
declare hold_list cursor for
select
H_T_ID,
H_QTY,
H_PRICEfrom

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 146 of 287

Trade-Result_Frame-2 Pseudo-code: Update the customer's holdings for buy or
sell
HOLDING
where
H_CA_ID = acct_id and
H_S_SYMB = symbol
order by
H_DTS asc}// Liquidate existing holdings.

Note that more than// 1 HOLDING record can be deleted here since customer// may have the same security with differing prices.
open hold_list
do until (needed_qty = 0 or end_of_hold_list) {fetch from
hold_list
into
hold_id,
hold_qty,
hold_priceif (hold_qty > needed_qty) then {//Selling some of the holdings
insert into
HOLDING_HISTORY (HH_H_T_ID,
HH_T_ID,
HH_BEFORE_QTY,
HH_AFTER_QTY)
values (hold_id,// H_T_ID of original trade

trade_id,// T_ID current tradehold_qty,// H_QTY now

hold_qty - needed_qty// H_QTY after update)
updateHOLDING
set
H_QTY = hold_qty - needed_qty
wherecurrent of hold_list
buy_value += needed_qty * hold_pricesell_value += needed_qty * trade_priceneeded_qty = 0

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 147 of 287

Trade-Result_Frame-2 Pseudo-code: Update the customer's holdings for buy orsell} else {// Selling all holdings
insert into
HOLDING_HISTORY (HH_H_T_ID,
HH_T_ID,
HH_BEFORE_QTY,
HH_AFTER_QTY)
values (hold_id,// H_T_ID original trade

trade_id,// T_ID current tradehold_qty,// H_QTY now0// H_QTY after delete)delete fromHOLDING
where
current of hold_list
buy_value += hold_qty * hold_pricesell_value += hold_qty * trade_priceneeded_qty = needed_qty - hold_qty}}
close hold_list}// Sell Short:// If needed_qty > 0 then customer has sold all existing// holdings and customer is selling short.

A new HOLDING// record will be created with H_QTY set to the negative// number of needed shares.
if (needed_qty > 0) then {insert into
HOLDING_HISTORY (HH_H_T_ID,
HH_T_ID,
HH_BEFORE_QTY,
HH_AFTER_QTY)
values (trade_id,// T_ID current is original trade

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 148 of 287

Trade-Result_Frame-2 Pseudo-code: Update the customer's holdings for buy orselltrade_id,// T_ID current trade0,// H_QTY before(-1) * needed_qty// H_QTY after insert)
insert into
HOLDING (H_T_ID,
H_CA_ID,
H_S_SYMB,
H_DTS,
H_PRICE,
H_QTY)
values (trade_id,// H_T_ID

acct_id,// H_CA_ID

symbol,// H_S_SYMB

trade_dts,// H_DTS

trade_price,// H_PRICE(-1) * needed_qty//* H_QTY)
else
if (hs_qty = trade_qty) thendelete fromHOLDING_SUMMARY
where
HS_CA_ID= acct_id and

HS_S_SYMB= symbol}} else {// The trade is a BUY

if (hs_qty == 0) then// no prior holdings exist, but one will be inserted

insert into
HOLDING_SUMMARY (HS_CA_ID,
HS_S_SYMB,
HS_QTY)values (acct_id,
symbol,trade_qty)
else// hs_qty != 0

if (-hs_qty != trade_qty) then

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 149 of 287

Trade-Result_Frame-2 Pseudo-code: Update the customer's holdings for buy orsell
updateHOLDING_SUMMARY
set
HS_QTY = hs_qty + trade_qty
where
HS_CA_ID= acct_id and

HS_S_SYMB= symbol// Short Cover:// First look for existing negative holdings, H_QTY < 0,// which indicates a previous short sell.

The buy trade// will cover the short sell.
if (hs_qty < 0) then {if (is_lifo) then {// Could return 0, 1 or many rows
declare hold_list cursor for
select
H_T_ID,
H_QTY,
H_PRICE
fromHOLDING
where
H_CA_ID = acct_id and
H_S_SYMB = symbol
order by
H_DTS desc
} else {// Could return 0, 1 or many rows
declare hold_list cursor for
select
H_T_ID,
H_QTY,
H_PRICE
fromHOLDING
where
H_CA_ID = acct_id and
H_S_SYMB = symbol
order by
H_DTS asc}// Buy back securities to cover a short position.
open hold_list

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 150 of 287

Trade-Result_Frame-2 Pseudo-code: Update the customer's holdings for buy orsell
do until (needed_qty = 0 or end_of_hold_list) {fetch from
hold_list
into
hold_id,
hold_qty,
hold_priceif (hold_qty + needed_qty < 0) then {// Buying back some of the Short Sell
insert into
HOLDING_HISTORY (HH_H_T_ID,
HH_T_ID,
HH_BEFORE_QTY,
HH_AFTER_QTY)
values (hold_id,// H_T_ID original trade

trade_id,// T_ID current tradehold_qty,// H_QTY now

hold_qty + needed_qty// H_QTY after update)
updateHOLDING
set
H_QTY = hold_qty + needed_qty
wherecurrent of hold_list
sell_value += needed_qty * hold_pricebuy_value += needed_qty * trade_priceneeded_qty = 0} else {// Buying back all of the Short Sell
insert into
HOLDING_HISTORY (HH_H_T_ID,
HH_T_ID,
HH_BEFORE_QTY,
HH_AFTER_QTY)
values (hold_id,// H_T_ID original trade

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 151 of 287

Trade-Result_Frame-2 Pseudo-code: Update the customer's holdings for buy orselltrade_id,// T_ID current tradehold_qty,// H_QTY now0// H_QTY after delete)delete fromHOLDING
where
current of hold_list// Make hold_qty positive for easy calculations
hold_qty = -hold_qty
sell_value += hold_qty * hold_pricebuy_value += hold_qty * trade_priceneeded_qty = needed_qty - hold_qty}}
close hold_list}// Buy Trade:// If needed_qty > 0, then the customer has covered all// previous Short Sells and the customer is buying new// holdings. A new HOLDING record will be created with// H_QTY set to the number of needed shares.
if (needed_qty > 0) then {insert into
HOLDING_HISTORY (HH_H_T_ID,
HH_T_ID,
HH_BEFORE_QTY,
HH_AFTER_QTY)
values (trade_id,// T_ID current is original trade

trade_id,//* T_ID current trade0,// H_QTY before

needed_qty// H_QTY after insert)
insert into
HOLDING (H_T_ID,
H_CA_ID,
H_S_SYMB,TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 152 of 287

Trade-Result_Frame-2 Pseudo-code: Update the customer's holdings for buy or
sell
H_DTS,
H_PRICE,
H_QTY)
values (trade_id// H_T_ID

acct_id,// H_CA_ID

symbol,// H_S_SYMB

trade_dts,// H_DTS

trade_price, // H_PRICE
needed_qty// H_QTY)}
else
if (-hs_qty = trade_qty) thendelete fromHOLDING_SUMMARY
where
HS_CA_ID= acct_id and

HS_S_SYMB= symbol}}

3.3.8.5

Trade-Result Transaction Frame 3 of 6

The third Frame is responsible for computing the amount of tax due by the customer as a result of the
trade. Frame 3 is only executed if the customer is liquidating existing holdings, and the liquidation has
resulted in a gain, and the customer's tax status is either 1 or 2. The amount of tax due is recorded in
the TRADE table.
Comment: The parameter tax_amount is used by the EGenTxnHarness to compute the value of theparameter se_amount just before Frame 6. Thus, the parameter tax_amount is initialized to zero and ispassed in and out of Frame 3.
The database access methods used in Frame 3 are a mixture of References and Modifies.
The EGenTxnHarness controls the execution of Frame 3 as follows:

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 153 of 287

{
tax_amount = 0.00
if ((tax_status == 1 or tax_status == 2)
and (sell_value > buy_value)) then{invoke (Trade-Result_Frame-3)
if (tax_amount <= 0.00) then{status = -831}}}
Trade-Result Frame 3 of 6 Parameters:
Parameter

Direction

Description

buy_valueIN

The total dollar amount for the securities bought for a matching sell order.

cust_idIN

Customer ID of the customer involved in the Trade-Result transaction, which was
obtained in Frame 1.

sell_value

IN

The total dollar value of the securities sold for a matching buy order.

trade_id

IN

The Trade ID for the trade to be settled passed to the transaction by the MarketExchange-Emulator.

tax_amount

OUT

Tax_amount is initialized to 0.0 by the EGen code and modified by Frame 3.

Trade-Result_Frame-3 Pseudo-code: Compute and record the tax liability{// Local Frame variables
Declare tax_rates

S_PRICE_T

selecttax_rates = sum(TX_RATE)fromTAXRATE
where
TX_ID in ( selectCX_TX_ID
from
CUSTOMER_TAXRATE
where
CX_C_ID = cust_id)
tax_amount = (sell_value – buy_value) * tax_rates

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 154 of 287

Trade-Result_Frame-3 Pseudo-code: Compute and record the tax liability
updateTRADE
set
T_TAX = tax_amount
where
T_ID = trade_id}

3.3.8.6

Trade-Result Transaction Frame 4 of 6

The fourth Frame is responsible for computing the commission for the broker who executed the trade.
The database access methods used in Frame 4 are all References.
The EGenTxnHarness controls the execution of Frame 4 as follows:{
invoke (Trade-Result_Frame-4)
if (comm_rate <= 0.00) then{status = -841}}
Trade-Result Frame 4 of 6 Parameters:
Parameter

Direction

Description

cust_idIN

Customer ID of the customer involved in the Trade-Result transaction, which was
obtained in Frame 1.

symbolIN

Seven character security identifier, which was obtained in Frame 1

trade_qty

IN

Quantity of securities traded, which was obtained in Frame 1

type_idIN

Trade type identifier, which was obtained in Frame 1

comm_rate

OUT

The broker commission rate. Ranges from 0.00 to 100.00.

s_nameOUT

Name of security traded

Trade-Result_Frame-4 Pseudo-code: Compute and record the broker's commission{
selects_ex_id = S_EX_ID,
s_name= S_NAME

fromTPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 155 of 287

Trade-Result_Frame-4 Pseudo-code: Compute and record the broker's commission
SECURITY
where
S_SYMB = symbol
selectc_tier = C_TIER
fromCUSTOMER
where
C_ID = cust_id// Only want 1 commission rate row
select first 1 row
comm_rate = CR_RATE
fromCOMMISSION_RATE
where
CR_C_TIER = c_tier and
CR_TT_ID = type_id and
CR_EX_ID = s_ex_id and
CR_FROM_QTY <= trade_qty and
CR_TO_QTY >= trade_qty}

3.3.8.7

Trade-Result Transaction Frame 5 of 6

The fifth Frame is responsible for recording the result of the trade and the broker's commission.
The database access methods used in Frame 5 are a mixture of Modifies, Adds and Removes.
The EGenTxnHarness controls the execution of Frame 5 as follows:{
comm_amount = (comm_rate / 100) * (trade_qty * trade_price)invoke (Trade-Result_Frame-5)}
Trade-Result Frame 5 of 6 Parameters:
Parameter

Direction

Description

broker_id

IN

Broker ID, which was obtained in Frame 1.

comm_amountIN

The broker commission amount, computed by the EGen code

st_completed_id

IN

The index ID value into STATUS_TYPE for “Completed” status.

trade_dts

IN

Trade date and time provided by the output of Frame 2.

trade_id

IN

The Trade ID for the trade to be settled passed to the transaction by the Market
Exchange Emulator.

trade_priceIN

Trade price provided by the Market Exchange Emulator.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 156 of 287

Trade-Result_Frame-5 Pseudo-code: Record the trade result and the broker's
commission{
updateTRADE
set
T_COMM= comm_amount,

T_DTS= trade_dts,

T_ST_ID= st_completed_id,

T_TRADE_PRICE = trade_price
where
T_ID = trade_id
insert into
TRADE_HISTORY (TH_T_ID,
TH_DTS,
TH_ST_ID)
values (trade_id,
trade_dts,
st_completed_id)
updateBROKERset
B_COMM_TOTAL = B_COMM_TOTAL + comm_amount,
B_NUM_TRADES = B_NUM_TRADES + 1
where
B_ID = broker_id}

3.3.8.8

Trade-Result Transaction Frame 6 of 6

The sixth Frame is responsible for settling the trade.
The database access methods used in Frame 6 are a mixture Adds and Modifies.
The EGenTxnHarness controls the execution of Frame 6 as follows:

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 157 of 287

{due_date = (trade_date + 2 days)
if (type_is_sell) then{se_amount = (trade_qty * trade_price) – charge – comm_amount} else {se_amount = -((trade_qty * trade_price) + charge + comm_amount)}
if (tax_status == 1) then{se_amount = se_amount – tax_amount}invoke (Trade-Result_Frame-6)}
Trade-Result Frame 6 of 6 Parameters:
Parameter

Direction

Description

acct_idIN

Customer account ID of the customer involved in the Trade-Result transaction,
which was obtained in Frame 1.

due_date

IN

Date and time when trade is due to be settled.

s_nameIN

Name of security traded, which was obtained in Frame 4

se_amount

IN

The trade settlement amount.

trade_dts

IN

Date and time of trade result generated by the SUT, and output in Frame 2.

trade_idIN

The trade ID for the trade to be settled, passed to the transaction by the Market
Exchange Emulator.

trade_is_cash

IN

Boolean obtained in Frame 1 indicating trade is for cash (1) or on margin (0).

trade_qty

IN

Quantity of securities traded, which was obtained from Frame 1

type_nameIN

Trade type name, which was obtained in Frame 1.

acct_bal

OUT

Customer account’s cash balance (needed for one of the isolation tests)

Trade-Result_Frame-6 Pseudo-code: Settle the trade{// Local Frame Variables
Declare cash_type char(40)if (trade_is_cash) thencash_type = “Cash Account”
else
cash_type = “Margin”

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 158 of 287

Trade-Result_Frame-6 Pseudo-code: Settle the tradeinsert into
SETTLEMENT (SE_T_ID,
SE_CASH_TYPE,
SE_CASH_DUE_DATE,SE_AMT)values (trade_id,
cash_type,
due_date,
se_amount)
if (trade_is_cash) then {updateCUSTOMER_ACCOUNT
set
CA_BAL = CA_BAL + se_amount
where
CA_ID = acct_id
insert into
CASH_TRANSACTION (CT_DTS,
CT_T_ID,
CT_AMT,
CT_NAME)values (trade_dts,
trade_id,
se_amount,
type_name + " " + trade_qty + " shares of " + s_name)}selectacct_bal = CA_BAL
from
CUSTOMER_ACCOUNT
where
CA_ID = acct_id
commit transaction

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 159 of 287

Trade-Result_Frame-6 Pseudo-code: Settle the trade

}

3.3.9

The Trade-Status Transaction
The Trade-Status Transaction is designed to emulate the process of providing an update on the statusof a particular set of trades. It is representative of a customer reviewing a summary of the recent
trading activity for one of their accounts.
Trade-Status is invoked by EGenDriverCE. It consists of a single Frame. For the given account ID,
Trade-Status returns the trade ID and status of the 50 most recent trades.

3.3.9.1

Trade-Status Transaction Parameters

The inputs to the Trade-Status Transaction are generated by the EGenDriverCE code in
CETxnInputGenerator.cpp and the data structures defined in TxnHarnessStructs.h must be used tocommunicate the input and output parameters.
Trade-Status Interfaces

Module/Data Structure

CE Input generation

GenerateTradeStatusInput()

Transaction Input/Output Structure

TTradeStatusTxnInput
TTradeStatusTxnOutput

Frame 1 Input/Output Structure

TTradeStatusFrame1Input
TTradeStatusFrame1Output

Trade-Status Transaction Parameters:
Parameter

Direction

Description

acct_idIN

A single customer is chosen non-uniformly by customer tier, from the range ofavailable customers. The rules for determining the range of available customers aredescribed in clause 3.2.2.1. A single customer account id, as defined by CA_ID in
CUSTOMER_ACCOUNT, is chosen at random, uniformly, from the range ofcustomer account ids for the chosen customer.

statusOUT

Code indicating the execution status for this transaction.

status_name[]

OUT

A list of character strings, each character string as defined by ST_NAME in
STATUS_TYPE, representing the current status of a trade.

trade_id[]

OUT

A list of numbers, each number as defined by T_ID in TRADE, assigned by thebrokerage or exchange to identify the specific trade being requested.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 160 of 287

3.3.9.2

Trade-Status Transaction Database Footprint

The Trade-Status Database Footprint is as follows:
Trade-Status Database Footprint
Frame
Table

Column1

BROKER

B_NAME

ReturnC_F_NAME

ReturnC_L_NAME

ReturnEXCHANGE

EX_NAME

ReturnSECURITY

S_NAME

ReturnSTATUS_TYPE

ST_NAME

ReturnT_CHRG

ReturnT_DTS

ReturnCUSTOMER

T_EXEC_NAME Return

TRADE

TRADE_TYPE

T_ID

ReturnT_QTY

Return

T_S_SYMB

ReturnTT_NAME

ReturnTransaction Control

3.3.9.3

Start
CommitTrade-Status Transaction Frame 1 of 1

The database access methods used in Frame 1 are all Returns.
The EGenTxnHarness controls the execution of Frame 1 as follows:{
invoke (Trade-Status_Frame-1)
if (num_found <> max_trade_status_len) then{status = -911}}
Trade-Status Frame 1 of 1 Parameters:
Parameter

Direction

Description

acct_idIN

A single customer is chosen non-uniformly by customer tier, from the range ofavailable customers. The rules for determining the range of available customers
are described in clause 3.2.2.1. A single customer account id, as defined by
CA_ID in CUSTOMER_ACCOUNT, is chosen at random, uniformly, from therange of customer account ids for the chosen customer.

broker_name

OUT

A character string, as defined by B_NAME in BROKER, representing the name of
the broker who executes transactions on behalf of the customer

charge[ ]OUT

A list of numbers, each number as defined by T_CHRG in TRADE, representing
the cost of executing the trade as charged by the broker.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 161 of 287

cust_f_name

OUT

A character string, as defined by C_F_NAME in CUSTOMER, representing thefirst name of the customer who owns the account (acct_id).

cust_l_name

OUT

A character string, as defined by C_L_NAME in CUSTOMER, representing thelast name of the customer who owns the account (acct_id).

ex_name[ ]OUT

A list of character strings, each character string as defined by EX_NAME in
EXCHANGE, representing the name of the security exchange where the security
is traded.

exec_name[ ]OUT

A list of character strings, each character string as defined by T_EXEC_NAME in
TRADE, representing the name of the person who initiated the trade on behalf ofthe customer (c_f_name, c_l_name).

num_found

OUT

Number of TRADE rows found.

s_name[ ]OUT

A list of character strings, each character string as defined by S_NAME in
SECURITY, representing the name of the security as listed with the exchange.

status_name[ ]OUT

A list of character strings, each character string as defined by ST_NAME in
STATUS_TYPE, representing the current status of the trade.

symbol [ ]OUT

A list of character strings, each character string as defined by S_SYMB in
SECURITY, representing the specific security, as listed with the exchange, being
traded in the trade.

trade_dts[ ]OUT

A list of dates and times, each data and time as defined by T_DTS in TRADE, atwhich the Trade-Request was processed by the broker.

trade_id[ ]OUT

A list of numbers, each number as defined by T_ID in TRADE, assigned by thebrokerage or exchange to identify the specific trade being requested.

trade_qty[ ]OUT

A list of numbers, each number as defined by T_QTY in TRADE, representing
the quantity of the security being traded in the Trade-Request.

type_name[ ]OUT

A list of character strings, each character string as defined by TT_NAME in
TRADE_TYPE, representing the type of trade being executed on behalf of thecustomer.

Trade-Status_Frame-1 Pseudo-code: Retrieve information on the 50 most recent
trades{start transaction// Only want 50 rows, the 50 most recent trades for this customer accountselect first 50 row
trade_id[]= T_ID,

trade_dts[]= T_DTS,status_name[] = ST_NAME,
type_name[]= TT_NAME,

symbol[]= T_S_SYMB,

trade_qty[]= T_QTY,

exec_name[]= T_EXEC_NAME,

charge[]= T_CHRG,

s_name[]= S_NAME,

ex_name[]= EX_NAME

fromTRADE,TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 162 of 287

Trade-Status_Frame-1 Pseudo-code: Retrieve information on the 50 most recent
tradesSTATUS_TYPE,
TRADE_TYPE,SECURITY,EXCHANGE
where
T_CA_ID = acct_id and
ST_ID = T_ST_ID and
TT_ID = T_TT_ID and
S_SYMB = T_S_SYMB and
EX_ID = S_EX_ID
order by
T_DTS desc
num_found = row_countselectcust_l_name = C_L_NAME,
cust_f_name = C_F_NAME,
broker_name = B_NAME
fromCUSTOMER_ACCOUNT,CUSTOMER,BROKER
where
CA_ID = acct_id and
C_ID = CA_C_ID and
B_ID = CA_B_ID
commit transaction}

3.3.10The Trade-Update Transaction
The Trade-Update Transaction is designed to emulate the process of making minor corrections or
updates to a set of trades. This is analogous to a customer or broker reviewing a set of trades, anddiscovering that some minor editorial corrections are required. The various sets of trades are chosensuch that the work is representative of:

reviewing general market trends

reviewing trades for a period of time prior to the most recent account statementreviewing past performance of a particular security

Trade-Update is invoked by EGenDriverCE. It consists of three mutually exclusive Frames. Each
Frame employs a different technique for looking up historical trade data. Minor corrections are made to
the retrieved data.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 163 of 287

Frame 1 accepts a list of trade IDs. Information for each of the trades in the list is returned. The
executor’s name for each trade is modified.
Frame 2 accepts a customer account ID, a start timestamp, end timestamp and a number of trades (N)as inputs. The Frame returns information for the first N trades for the specified customer accountbetween the start and end timestamps (inclusive). The settlement cash type for each trade is modified.
Frame 3 accepts a security symbol, a start timestamp, end timestamp and a number of trades (N) as
inputs. The Frame returns information for the first N trades for the given security between the start andend timestamps (inclusive). For cash trades the description of the Transaction is modified.
3.3.10.1

Trade-Update Transaction Parameters

The inputs to the Trade-Update Transaction are generated by the EGenDriverCE code in
CETxnInputGenerator.cpp. The data structures defined in TxnHarnessStructs.h must be used tocommunicate the input and output parameters.
Trade-Update Interfaces

Module/Data Structure

CE Input generation

GenerateTradeUpdateInput()

Transaction Input/Output
Structure

TTradeUpdateTxnInput
TTradeUpdateTxnOutput

Frame 1 Input/Output Structure

TTradeUpdateFrame1Input
TTradeUpdateFrame1Output

Frame 2 Input/Output Structure

TTradeUpdateFrame2Input
TTradeUpdateFrame2Output

Frame 3 Input/Output Structure

TTradeUpdateFrame3Input
TTradeUpdateFrame3Output

Trade-Update Transaction Parameters:
Parameter

Direction

Description

acct_idIN

Customer account ID. Used when frame_to_execute is 2, otherwise set to 0.

end_trade_dts

IN

Used in Frame 2 as the end point in time for identifying a particular trade for an
account.
Used in Frame 3 as the end point in time for identifying trades for a particularsymbol.
For Frame 1, this parameter is ignored, so it is set to an empty date.

frame_to_execute

IN

Identifies which of the mutually exclusive frames to execute.

max_acct_id

INMaximum account identifier, used in Frame 3, otherwise set to 0.

max_tradesIN

Maximum number of trades to find. The default value (20) is defined in the
TTradeUpdateSettings structure in DriverParameterSettings.h.

max_updatesIN

Maximum number of trades to be modified. The default value (20) is defined in
the TTradeUpdateSetting structure in DriverParameterSettings.h.

start_trade_dts

IN

Used in Frame 2 as the point in time for identifying a particular trade for an
account.
Non-uniform over pre-populated interval.
Used in Frame 3 as the point in time for identifying trades for a particularsymbol.
Uniform over pre-populated interval.
For Frame 1, this parameter is ignored, so it is set to an empty date.

symbolIN

Used in Frame 3 as the security symbol for which to find trades. Uniformly
chosen over all securities. For the other frames, symbol is set to the empty string.

trade_id[ ]IN

Array of non-uniform randomly chosen trade IDs used by Frame 1 to identify aset of particular trades. For the other frames, array elements are set to 0. For
Frame 1, max_trades indicates how many elements are to be used in the array.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 164 of 287

3.3.10.2

frame_executed

OUT

Confirmation of which frame was executed.

is_cash[ ]OUT

Indicates whether the trades were cash transactions.

is_market[ ]OUT

Indicates whether the trades used in Frame 1 were market order trades.

num_found

OUT

Number of trade rows found for frames 1, 2 and 3.

num_updated

OUT

Number of trade rows modified for frames 1, 2 and 3.

statusOUT

Code indicating the execution status for this transaction.

trade_list[ ]OUT

List of trade IDs found in Frames 2 and 3.

Trade-Update Transaction Database Footprint

The Trade-Update Database Footprint is as follows:
Trade-Update Database Footprint
Frame
Table

CASH_TRANSACTION

SECURITY

Column1*2*3*

CT_AMT

Return*Return*Return*CT_DTS

Return*Return*Return*CT_NAME

Return*Return*Modify*Return*S_NAME
SE_AMTSETTLEMENT

ReturnReturnReturnReturnSE_CASH_DUE_DATE Return

ReturnReturnSE_CASH_TYPE

ReturnModifyReturnReturnT_BID_PRICE

ReturnReturn

T_CA_ID

Return

T_DTS
T_EXEC_NAME
TRADE

Reference Reference
ModifyReturn

T_ID
T_IS_CASH

ReturnReturnReturnReturnReturnReturnReturnT_QTY

Return

T_S_SYMB

Reference

T_TRADE_PRICE

ReturnReturnT_TT_ID
TRADE_HISTORY

TRADE_TYPE

Transaction Control

ReturnReturnTH_DTS

ReturnReturnReturn

TH_ST_ID

ReturnReturnReturnTT_IS_MRKTReturnTT_NAME

ReturnStart
StartCommit Commit

StartCommit

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 165 of 287

3.3.10.3

Trade-Update Transaction Frame 1 of 3

The first Frame is responsible for retrieving information about the specified array of trade IDs andmodifying some data from the TRADE table.
The EGenTxnHarness controls the execution of Frame 1 as follows:{if( frame_to_execute == 1 ){invoke (Trade-Update_Frame-1)
if (num_found != max_trades) then{status = -1011}
if (num_updated != max_updates) then{status = -1012}
frame_executed = 1}[...]
Trade-Update Frame 1 of 3 Parameters:
Parameter

Direction

Description

max_tradesIN

Number of valid array elements in trade_id[ ]. The default value (20)is set in TTradeUpdateSettings.MaxRowsFrame1 in
DriverParameterSettings.h.

max_updatesIN

Maximum number of TRADE rows to modify. The default value (20)is set in TTradeUpdateSettings.MaxRowsToUpdateFrame1 in
DriverParameterSettings.h. Must be <= max_trades.

trade_id[ ]INThe array of trade IDs picked non-uniformly over the set of prepopulated trades.

bid_price[ ]OUTThe requested unit price.

cash_transaction_amount[ ]OUT

Amount of the cash transaction.

cash_transaction_dts[ ]OUT

Date and time stamp of when the transaction took place.

cash_transaction_name[ ]OUT

Description of the cash transaction.

exec_name[ ]OUTName of the person who executed the trade.

is_cash[ ]OUT

Flag that is non-zero for a cash trade, zero for a margin trade.

is_market[ ]OUT

Flag that is non-zero for a market trade, zero for a limit trade.

num_found

OUT

Number of trade rows returned; should be the same as max_trades.

num_updated

OUT

Number of TRADE rows that were modified; should be the same as
max_updates.

settlement_amount[ ]OUT

Cash amount of settlement.

settlement_cash_due_date[ ]OUT

Date by which customer or brokerage must receive the cash.

settlement_cash_type[ ]OUT

Type of cash settlement involved: cash or margin.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 166 of 287

trade_history_dts[ ][3]OUT

Array of timestamps of when the trade history was updated.

trade_history_status_id[ ][3]OUT

Array of status type identifiers.

trade_price[ ]OUT

Unit price at which the security was traded.

Trade-Update_Frame-1 Pseudo-code: Get trade information for each trade ID in
the trade_id array and modify some of the TRADE rows.

{
declare i int
declare ex_name char(49)start transaction
num_found = 0
num_updated = 0
for (i = 0; i++; i < max_trades) do {// Get trade information
if (num_updated < max_updates) then {// Modify the TRADE row for this trade.
selectex_name = T_EXEC_NAME
from
TRADE
where
T_ID = trade_id[i]num_found = num_found + row_countif (ex_name like “% X %”) thenselect ex_name = REPLACE (ex_name, “ X “, “ “)elseselect ex_name = REPLACE (ex_name, “ “, “ X “)
updateTRADE
set
T_EXEC_NAME = ex_name
where
T_ID = trade_id[i]num_updated = num_updated + row_count}// Will only return one row for each trade
select

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 167 of 287

Trade-Update_Frame-1 Pseudo-code: Get trade information for each trade ID in
the trade_id array and modify some of the TRADE rows.
bid_price[i]= T_BID_PRICE,

exec_name[i]= T_EXEC_NAME,

is_cash[i]= T_IS_CASH,

is_market[i]= TT_IS_MRKT,

trade_price[i] = T_TRADE_PRICE
fromTRADE,TRADE_TYPE
where
T_ID = trade_id[i] andT_TT_ID = TT_ID// Get settlement information// Will only return one row for each trade
selectsettlement_amount[i]= SE_AMT,

settlement_cash_due_date[i] = SE_CASH_DUE_DATE,
settlement_cash_type[i]= SE_CASH_TYPE

from
SETTLEMENT
where
SE_T_ID = trade_id[i]// get cash information if this is a cash transaction// Will only return one row for each trade that was a cash transaction
if (is_cash[i]) then {selectcash_transaction_amount[i] = CT_AMT,
cash_transaction_dts[i]= CT_DTS,

cash_transaction_name[i]= CT_NAME

from
CASH_TRANSACTION
where
CT_T_ID = trade_id[i]}// read trade_history for the trades// Will return 2 or 3 rows per trade
select first 3 rows
trade_history_dts[i][]= TH_DTS,

trade_history_status_id[i][] = TH_ST_ID
from
TRADE_HISTORY
where
TH_T_ID = trade_id[i]order by

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 168 of 287

Trade-Update_Frame-1 Pseudo-code: Get trade information for each trade ID in
the trade_id array and modify some of the TRADE rows.
TH_DTS} // end for loop
commit transaction}

3.3.10.4

Trade-Update Transaction Frame 2 of 3

The second Frame returns information for the first N trades executed for the specified customer
account between a specified start time and end time and modifies the SETTLEMENT row for each trade
returned. If the specified start time is too close to the specified end time, then it is possible that fewer
than N trades may be returned and SETTLEMENT rows modified.
The EGenTxnHarness controls the execution of Frame 2 as follows:[...]else if( frame_to_execute == 2 ){invoke (Trade-Update_Frame-2)
if ((num_found < 0) or (num_found > max_trades)){status = -1021}
if (num_updated == 0){
status = +1021}
else if (num_updated <> num_found){status = -1022}

frame_executed = 2}[...]
Trade-Update Frame 2 of 3 Parameters:
Parameter

acct_id

Direction

DescriptionIN

A single customer is chosen non-uniformly by customer tier, fromthe range of available customers. The rules for determining therange of available customers are described in clause 3.2.2.1. A
single customer account id, as defined by CA_ID in
CUSTOMER_ACCOUNT, is chosen at random, uniformly, from the

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 169 of 287

range of customer account ids for the chosen customer.
end_trade_dts

IN

Point in time at which to stop the search for N trades.

max_tradesIN

Maximum number of trades to return. The default value (20) is set
in TTradeUpdateSettings.MaxRowsFrame2 in
DriverParameterSettings.h.

max_updatesIN

Maximum number of SETTLEMENT rows to modify. The default
value (20) is set in
TTradeUpdateSettings.MaxRowsToUpdateFrame2 in
DriverParameterSettings.h.

start_trade_dts

IN

Point in time from which to search for N trades.

bid_price[ ]OUTThe requested unit price.

cash_transaction_amount[ ]OUT

Amount of the cash transaction.

cash_transaction_dts[ ]OUT

Date and time stamp of when the transaction took place.

cash_transaction_name[ ]OUT

Description of the cash transaction.

exec_name[ ]OUTName of the person who executed the trade.

is_cash[ ]OUT

Flag that is non-zero for a cash trade, zero for a margin trade.

num_found

OUT

Number of trade rows returned.

num_updated

OUT

Number of SETTLEMENT rows that were modified.

settlement_amount[ ]OUT

Cash amount of settlement.

settlement_cash_due_date[ ]OUT

Date by which customer or brokerage must receive the cash.

settlement_cash_type[ ]OUT

Type of cash settlement involved: cash or margin.

trade_history[ ][3]OUT

Array of timestamps of when the trade history was updated.

trade_history_status_id[ ][3]OUT

Array of status type identifiers.

trade_list[ ]OUT

Trade ID actually used for retrieving data.

trade_price[ ]OUT

Unit price at which the security was traded.

Trade-Update_Frame-2 Pseudo-code : Get trade information for the first N
trades of a given customer account from a given point in time and modify
some of the SETTLEMENT rows.

{
declare i int
declare cash_type char(40)start transaction// Get trade information// Will return between 0 and max_trades rows
select first max_trades rows
bid_price[]= T_BID_PRICE,

exec_name[]= T_EXEC_NAME,

is_cash[]= T_IS_CASH,

trade_list[]= T_ID,

trade_price[] = T_TRADE_PRICETPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 170 of 287

Trade-Update_Frame-2 Pseudo-code : Get trade information for the first N
trades of a given customer account from a given point in time and modify
some of the SETTLEMENT rows.
from
TRADE
where
T_CA_ID = acct_id and
T_DTS >= start_trade_dts and
T_DTS <= end_trade_dts
order by
T_DTS asc
num_found= row_countnum_updated = 0// Get extra information for each trade in the trade list.
for (i = 0; i < num_found; i++) {if (num_updated < max_updates) then {// Modify the SETTLEMENT row for this trade.
selectcash_type = SE_CASH_TYPE
from
SETTLEMENT
where
SE_T_ID = trade_list[i]if (is_cash[i]) then {if (cash_type == “Cash Account”) thencash_type = “Cash”
else
cash_type = “Cash Account”}
else
if (cash_type == “Margin Account”) thencash_type = “Margin”
else
cash_type = “Margin Account”}
updateSETTLEMENT
set
SE_CASH_TYPE = cash_type
where
SE_T_ID = trade_list[i]num_updated = num_updated + row_count

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 171 of 287

Trade-Update_Frame-2 Pseudo-code : Get trade information for the first N
trades of a given customer account from a given point in time and modify
some of the SETTLEMENT rows.
}// Get settlement information// Will return only one row for each trade
selectsettlement_amount[i]= SE_AMT,

settlement_cash_due_date[i] = SE_CASH_DUE_DATE,
settlement_cash_type[i]= SE_CASH_TYPE

from
SETTLEMENT
where
SE_T_ID = trade_list[i]// get cash information if this is a cash transaction// Should return only one row for each trade that was a cash transaction
if (is_cash[i]) then {selectcash_transaction_amount[i] = CT_AMT,
cash_transaction_dts[i]= CT_DTS

cash_transaction_name[i]= CT_NAME

from
CASH_TRANSACTION
where
CT_T_ID = trade_list[i]}// read trade_history for the trades// Will return 2 or 3 rows per trade
select first 3 rows
trade_history_dts[i][]= TH_DTS,

trade_history_status_id[i][] = TH_ST_ID
from
TRADE_HISTORY
where
TH_T_ID = trade_list[i]order by
TH_DTS} // end for loop
commit transaction}

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 172 of 287

3.3.10.5

Trade-Update Transaction Frame 3 of 3

The third Frame returns information for the first N trades for a given security between a specified start
time and end time and modifies the related CASH_TRANSACTION row for each trade returned. If thespecified start time is too close to the specified end time, then it is possible that fewer than N trades
may be returned and CASH_TRANSACTION rows modified.
.
The EGenTxnHarness controls the execution of Frame 3 as follows:[...]else if( frame_to_execute == 3 ){invoke (Trade-Update_Frame-3)
if ((num_found < 0) or (num_found > max_trades)) then{status = -1031}
if (num_updated == 0){
status = +1032}
else if (num_updated > num_found) then{status = -1032}
frame_executed = 3}}
Trade-Update Frame 3 of 3 Parameters:
Parameter

Direction

Description

end_trade_dts

IN

Point in time at which to stop search.

max_acct_id

INMaximum customer account identifier.

max_tradesIN

Number of trades to find. The default value (20) is set in
TTradeUpdateSettings.MaxRowsFrame3 in DriverParameterSettings.h.

max_updates

IN

Number of CASH_TRANSACTION rows to modify. The default value(20) is set in TTradeUpdateSettings.MaxRowsToUpdateFrame3 in
DriverParameterSettings.h.

start_trade_dts

IN

Point in time from which to start search.

symbolIN

Security for which to find trades.

acct_id[ ]OUT

Array of accounts for which the trades were done.

cash_transaction_amount[ ]OUT

Amount of the cash transaction.

cash_transaction_dts[ ]OUT

Date and time stamp of when the transaction took place.

cash_transaction_name[ ]OUT

Description of the cash transaction.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 173 of 287

exec_name[ ]OUTArray of name of the person who executed each of the trades.

is_cash[ ]OUT

Flag that is non-zero for a cash trade, zero for a margin trade.

num_found

OUT

Number of TRADE rows returned.

num_updated

OUT

Number of CASH_TRANSACTION rows modified.

price[ ]OUTArray of the price that was paid in each trade.

quantity[ ]OUTArray of the quantity of security bought in each trade.

s_name[ ]OUTName of the security traded.

settlement_amount[ ]OUT

Cash amount of settlement.

settlement_cash_due_date[ ]OUT

Date by which the customer or brokerage must receive the cash.

settlement_cash_type[ ]OUT

Type of cash settlement involved: cash or margin.

trade_dts[ ]OUTArray of the timestamps for when the trade was requested.

trade_history_dts[ ][3]OUT

Array of timestamps of when the trade history was updated.

trade_history_status_id[ ][3]OUT

Array of status type identifiers.

trade_list[ ]OUTArray of T_IDs found.

type_name[ ]OUTArray of the trade type name for each trade.

trade_type[ ]OUTArray of the trade type for each trade.

Trade-Update_Frame-3 Pseudo-code: Get a list of N trades executed for acertain security starting from a given point in time and modify some of the
CASH_TRANSACTION rows.

{
declare i int
declare ct_name char(100)start transaction// Will return between 0 and max_trades rows.
select first max_trades rows
acct_id[]= T_CA_ID,

exec_name[]= T_EXEC_NAME,

is_cash[]= T_IS_CASH,

price[]= T_TRADE_PRICE,

quantity[]= T_QTY,s_name[]= S_NAME,

trade_dts[]= T_DTS,

trade_list[] = T_ID,
trade_type[] = T_TT_ID,
type_name[]= TT_NAME

fromTRADE,TRADE_TYPE,SECURITY
where
T_S_SYMB = symbol and

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 174 of 287

Trade-Update_Frame-3 Pseudo-code: Get a list of N trades executed for acertain security starting from a given point in time and modify some of the
CASH_TRANSACTION rows.
T_DTS >= start_trade_dts and
T_DTS <= end_trade_dts and
TT_ID = T_TT_ID and
S_SYMB = T_S_SYMB// The max_acct_id “where” clause is a hook used for engineering purposes// only and is not required for benchmark publication purposes.
// and//T_CA_ID <= max_acct_id
order by
T_DTS asc
num_found = row_countnum_updated = 0// Get extra information for each trade in the trade list.
for (i = 0; i < num_found; i++) {// Get settlement information// Will return only one row for each trade
selectsettlement_amount[i]= SE_AMT,

settlement_cash_due_date[i] = SE_CASH_DUE_DATE,
settlement_cash_type[i]= SE_CASH_TYPE

from
SETTLEMENT
where
SE_T_ID = trade_list[i]// get cash information if this is a cash transaction// Will return only one row for each trade that was a cash transaction
if (is_cash[i]) then {if (num_updated < max_updates) then {// Modify the CASH_TRANSACTION row for this trade.
selectct_name = CT_NAME
from
CASH_TRANSACTION
where
CT_T_ID = trade_list[i]if (ct_name like “% shares of %”) thenct_name = type_name[i] + “ “ + quantity[i] + “ Shares of “ + s_name[i]elsect_name = type_name[i] + “ “ + quantity[i] + “ shares of “ + s_name[i]TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 175 of 287

Trade-Update_Frame-3 Pseudo-code: Get a list of N trades executed for acertain security starting from a given point in time and modify some of the
CASH_TRANSACTION rows.

update
CASH_TRANSACTION
set
CT_NAME = ct_namewhere
CT_T_ID = trade_list[i]num_updated = num_updated + row_count}selectcash_transaction_amount[i] = CT_AMT,
cash_transaction_dts[i]= CT_DTS

cash_transaction_name[i]= CT_NAME

from
CASH_TRANSACTION
where
CT_T_ID = trade_list[i]}// read trade_history for the trades// Will return 2 or 3 rows per trade
select first 3 rows
trade_history_dts[i][]= TH_DTS,

trade_history_status_id[i][] = TH_ST_ID
from
TRADE_HISTORY
where
TH_T_ID = trade_list[i]order by
TH_DTS asc} // end for loop
commit transaction}

3.3.11

The Data-Maintenance Transaction
The Data-Maintenance Transaction is designed to emulate the periodic modifications to data that ismainly static and used for reference. This is analogous to updating

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 176 of 287

Data-Maintenance is invoked by EGenDriverDM. It consists of one Frame. This Transaction runs once
per minute. It simulates periodic modifications to data tables that are mainly used for reference by theother Transactions. The Driver provides as input the name of the table to be modified by theTransaction.
Each time this Transaction is run the Driver alters the next table in the list. This means that each tablein the list will only get altered once every twelve minutes.
The following is the list of table names that can be passed as arguments to this Transaction:

ACCOUNT_PERMISSIONADDRESSCOMPANYCUSTOMERCUSTOMER_TAXRATEDAILY_MARKET

EXCHANGEFINANCIAL

NEWS_ITEM

SECURITYTAXRATE

WATCH_ITEM

The Data-Maintenance Transaction consists of a single Frame.
The intent of the Transaction is to alter data tables that would not otherwise be written to by the
benchmark. The EGenTxnHarness will pick the next table in the list to alter, each time thisTransaction is run.
Below is a description of what kind of alteration is done to each table when that table is selected:
1.

ACCOUNT_PERMISSION - The EGenTxnHarness will pass a customer account identifier to the
Data-Maintenance Transaction. Each customer account will have at least one row in the
ACCOUNT_PERMISSION table. The first ACCOUNT_PERMISSION row for the customer will befound (The Sponsor may decide which row is first). That row in the ACCOUNT_PERMISSION
table will have an Access Control List (AP_ACL). That access control list will be updated to 1111 if
it is not already 1111. If the access control list is already 1111, the access control list will be updated
to 0011.

2.

ADDRESS – 67% of the time EGenTxnHarness will pass a customer identifier to the DataMaintenance Transaction. The other 33% of the time EGenTxnHarness will pass a company
identifier to the Data-Maintenance Transaction. That customer’s or company’s ADDRESS will be
modified. The AD_LINE2 will be set to “Apt. 10C” or to “Apt. 22” if it was already “Apt. 10C”.

3.

COMPANY – The EGenTxnHarness will pass a company identifier to the Data-MaintenanceTransaction. That company’s Standard and Poor credit rating will be updated to “ABA” or to“AAA” if it was already “ABA”.

4.

CUSTOMER – The EGenTxnHarness will pass a customer identifier to the Data-MaintenanceTransaction. The ISP part of that customer’s second email address (C_EMAIL_2) will be updated to“@mindspring.com” or to “@earthlink.com” if it was already “@mindspring.com”.

5.

CUSTOMER_TAXRATE – The EGenTxnHarness will pass a customer identifier to the DataMaintenance Transaction. The country tax rate will be modified cyclically to the next rate in the set{“US1”, “US2”, “US3”, “US4”, “US5”} or in the set {“CN1”, “CN2”, “CN3”, “CN4”}, depending on
the customer’s country.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 177 of 287

6.

DAILY_MARKET – The EGenTxnHarness will pass a security symbol, a day of the month, and arandom number (positive or negative) to the Data-Maintenance Transaction. All rows in
DAILY_MARKET with matching symbol and day of the month will be updated by adding therandom number to DM_VOL.

7.

EXCHANGE – The EGenTxnHarness will not pass any additional information to the DataMaintenance Transaction. There are only four rows in the EXCHANGE table. Every row will haveits EX_DESC updated. If EX_DESC does not already end with “LAST UPDATED “ and a date andtime, that string will be appended to EX_DESC. Otherwise the date and time at the end of
EX_DESC will be updated to the current date and time.

8.

FINANCIAL – The EGenTxnHarness will pass a company identifier to the Data-MaintenanceTransaction. That company’s FI_QTR_START_DATEs will be updated to the second of the monthor to the first of the month if the dates were already the second of the month.

9.

NEWS_ITEM – The EGenTxnHarness will pass a company identifier to the Data-MaintenanceTransaction. The NI_DTS for that company’s news items will be updated by one day.

10. SECURITY – The EGenTxnHarness will pass in a security symbol. That security’s S_EXCH_DATE
will be incremented by one day.
11. TAXRATE – The EGenTxnHarness will pass in tax rate identifier to the Data-MaintenanceTransaction. That tax rate’s TX_NAME will be updated so that a substring will be toggled between“Tax” and “tax”.
12. WATCH_ITEM – The EGenTxnHarness will pass in a customer identifier to the Data-MaintenanceTransaction. The middle security in the customer’s WATCH_ITEM list will be selected. It will be
modified to be the next symbol in the SECURITY table that is not already in the customer’s
WATCH_ITEM list.
3.3.11.1

Transaction Parameters

The inputs to the Data-Maintenance Transaction are generated by the EGenDriverDM in DM.cpp. The
data structures defined in TxnHarnessStructs.h must be used to communicate the input and output
parameters.
Data-Maintenance Interfaces

Module/Data Structure

Input generation

GenerateDataMaintenanceInput()

Transaction Input/Output Structure

TDataMaintenanceTxnInput
TDataMaintenanceTxnOutput

Frame 1 Input/Output Structure

TDataMaintenanceFrame1Input<none>

Data-Maintenance Transaction Parameters:
Parameter

acct_id

c_id

Direction

DescriptionIN

A single customer is chosen non-uniformly by customer tier, from therange of available customers. A single customer account id, as
defined by CA_ID in CUSTOMER_ACCOUNT, is chosen at random,
uniformly, from the range of customer account ids for the chosencustomer. This input is used when table_name is“ACCOUNT_PERMISSION”, otherwise it is set to 0.

IN

A number randomly selected from the possible customer identifiers
as defined by C_ID in CUSTOMER table using a uniform
distribution. This input is always used when table_name is“CUSTOMER”, “CUSTOMER_TAXRATE” or “WATCH_ITEM”. This
input (instead of co_id) is used 67% of the time when table_name is“ADDRESS”. Otherwise this input is set to 0.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 178 of 287

IN

A number randomly selected from the possible company identifiers
as defined by CO_ID in COMPANY table using a uniform
distribution. This input is always used when table_name is“COMPANY”, “FINANCIAL” or “NEWS_ITEM”. This input (insteadof c_id) is used 33% of the time when table_name is “ADDRESS”.
Otherwise this input is set to 0.

day_of_monthIN

A number randomly selected from 1 to 31 with a uniform
distribution. This input is only used when table_name is“DAILY_MARKET”, otherwise it is set to 0. When table_name is“DAILY_MARKET” all the rows with this day of the Month in
DM_DATE are modified.

symbolIN

A string containing a Security Symbol. The security symbol string
follows the definition of S_SYMB in the SECURITY table. This input
is only used when table_name is “DAILY_MARKET”, or“SECURITY”, otherwise it is set to empty string.

IN

A string containing the name of the table to be altered. Valid values
are “ACCOUNT_PERMISSION”, “ADDRESS”, “COMPANY”,“CUSTOMER”, “CUSTOMER_TAXRATE”, “DAILY_MARKET”,“EXCHANGE”, “FINANCIAL”, “NEWS_ITEM”, “SECURITY”,“TAXRATE”, “WATCH_ITEM”. This input is always used.

IN

A string containing a tax identifier. The tax identifier string follows
the definition of TX_ID in the TAXRATE table. This input is onlyused when table_name is “TAXRATE”, otherwise it is set to empty
string.

vol_incrIN

A randomly selected positive or negative number. This number isonly used when the table_name is “DAILY_MARKET”, otherwise
vol_incr is set to 0 and ignored. When table_name is“DAILY_MARKET” this number is added to DM_VOL.

statusOUT

Code indicating the execution status for this transaction.

co_id

table_nametx_id

3.3.11.2

Data-Maintenance Transaction Database Footprint

This Transaction includes a mix of Reference, Modify, Remove and Add operations. The Transaction
implementation would potentially require access to the following database tables and columns.
Data-Maintenance Database Footprint
Frame
Table Name

Column1

ACCOUNT_PERMISSIONADDRESSCOMPANYCUSTOMER

AP_ACL

Reference *Modify *AP_CA_ID

Reference *Count(*)

Reference *AD_ID

Reference *AD_LINE2

Reference *Modify (1 row)*

CO_AD_ID

Reference*

CO_ID

Reference *CO_SP_RATE

Reference *Modify (1 row)*

C_AD_ID

Reference *C_EMAIL_2

Reference *Modify (1 row)*

C_ID

Reference *TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 179 of 287

CX_C_ID
CUSTOMER_TAXRATEDAILY_MARKET

EXCHANGE

FINANCIALSECURITY

NEWS_ITEM

NEWS_XREFTAXRATECX_TX_ID

WATCH_LIST

Modify (1 row)*
Reference *DM_S_SYMB

Reference *DM_VOL

Reference *Modify *EX_DESC

Reference *Modify *Count(*)

Reference *FI_CO_ID

Reference *FI_QTR_START_DATE

Reference *Modify *Count(*)

Reference *S_EXCH_DATE

Modify *S_SYMB

Reference *NI_DTS

Modify *NI_ID

Reference *NX_CO_ID

Reference *NX_NI_ID

Reference *TX_ID

Reference *TX_NAME

Reference *Modify *Reference *Modify *WI_WL_ID

Reference *WL_C_ID

Reference *Transaction Control

3.3.11.3

Reference*

DM_DATEWI_S_SYMBWATCH_ITEM

Reference *StartCommitData-Maintenance Transaction Frame 1 of 1

The EGenTxnHarness controls the execution of Frame 1 as follows:{
invoke (Data-Maintenance_Frame-1)}
Data-Maintenance Frame 1 of 1 Parameters:
Parameter

Direction

Description

acct_idIN

A single customer is chosen non-uniformly by customer tier, fromthe range of available customers. A single customer account id, as
defined by CA_ID in CUSTOMER_ACCOUNT, is chosen at
random, uniformly, from the range of customer account ids for the
chosen customer. This input is used when table_name is“ACCOUNT_PERMISSION”, otherwise it is set to 0.

c_id

IN

A number randomly selected from the possible customer identifiers

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 180 of 287

as defined by C_ID in CUSTOMER table using a uniform
distribution. This input is always used when table_name is“CUSTOMER”, “CUSTOMER_TAXRATE” or “WATCH_ITEM”.
This input (instead of co_id) is used 67% of the time whentable_name is “ADDRESS”. Otherwise this input is set to 0.

IN

A number randomly selected from the possible company identifiers
as defined by CO_ID in COMPANY table using a uniform
distribution. This input is always used when table_name is“COMPANY”, “FINANCIAL” or “NEWS_ITEM”. This input(instead of c_id) is used 33% of the time when table_name is“ADDRESS”. Otherwise this input is set 0.

IN

A number randomly selected from 1 to 31 with a uniform
distribution. This input is only used when table_name is“DAILY_MARKET”, otherwise it is set to 0. When table_name is“DAILY_MARKET” all the rows with this day of the Month in
DM_DATE are modified.

IN

A string containing a Security Symbol. The security symbol string
follows the definition of S_SYMB in the SECURITY table. This input
is only used when table_name is “DAILY_MARKET”, or“SECURITY”, otherwise it is set to empty string.

table_nameIN

A string containing the name of the table to be altered. Valid values
are “ACCOUNT_PERMISSION”, “ADDRESS”, “COMPANY”,“CUSTOMER”, “CUSTOMER_TAXRATE”, “DAILY_MARKET”,“EXCHANGE”, “FINANCIAL”, “SECURITY”, “TAXRATE”,“WATCH_ITEM”. This input is always used.

tx_id

IN

A string containing a tax identifier. The tax identifier string follows
the definition of TX_ID in the TAXRATE table. This input is onlyused when table_name is “TAXRATE”, otherwise it is set to empty
string.

IN

A randomly selected positive or negative number. This number isonly used when the table_name is “DAILY_MARKET”, otherwise
vol_incr is set to 0 and ignored. When table_name is“DAILY_MARKET” this number is added to DM_VOL.

co_id

day_of_month

symbolvol_incr

Data-Maintenance Frame 1 Pseudo-code: Update a table/* Check which table is to be updated. */if (strcmp(table_name, “ACCOUNT_PERMISSION”)==0) {//ACCOUNT_PERMISSION//Update the AP_ACL to “1111” or “0011” in rows for a//customer account of c_id.
acl = NULL
select first 1 row
acl = AP_ACL
fromACCOUNT_PERMISSION
where
AP_CA_ID = acct_id
order by

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 181 of 287

Data-Maintenance Frame 1 Pseudo-code: Update a table
AP_ACL DESC
if (acl != “1111”) then {updateACCOUNT_PERMISSION
set
AP_ACL=”1111”
where
AP_CA_ID = acct_id and
AP_ACL = acl} else { /*ACL is “1111” change it to “0011” */updateACCOUNT_PERMISSION
set
AP_ACL = ”0011”
where
AP_CA_ID = acct_id and
AP_ACL = acl}} else if (strcmp(table_name,”ADDRESS”)==0) {// ADDRESS// Change AD_LINE2 in the ADDRESS table for// the CUSTOMER with C_ID of c_id or the COMPANY with CO_ID of co_id.
line2 = NULL
ad_id = 0// Customer ID provided
if (c_id != 0) {selectline2 = AD_LINE2,
ad_id = AD_ID
from
ADDRESS, CUSTOMER
where
AD_ID = C_AD_ID and
C_ID = c_id}// Company ID provided
else {
selectline2 = AD_LINE2,
ad_id = AD_ID
from
ADDRESS, COMPANY
where

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 182 of 287

Data-Maintenance Frame 1 Pseudo-code: Update a table
AD_ID = CO_AD_ID and
CO_ID = co_id}
if (strcmp(line2, “Apt. 10C”) != 0) {update
ADDRESSset
AD_LINE2 = “Apt. 10C”
where
AD_ID = ad_id} else {update
ADDRESSset
AD_LINE2 = “Apt. 22”
where
AD_ID = ad_id}} else if (strcmp(table_name,”COMPANY”)==0) {// COMPANY// Update a row in the COMPANY table identified// by co_id, set the company’s Standard and Poor// credit rating to “ABA” or to “AAA”.
sprate = NULL
selectsprate = CO_SP_RATE
fromCOMPANY
where
CO_ID = co_id
if (strcmp(sprate, “ABA”) != 0) {updateCOMPANY
set
CO_SP_RATE = “ABA”
where
CO_ID = co_id} else {updateCOMPANY
set
CO_SP_RATE = “AAA”
where
CO_ID = co_id}} else if (strcmp(table_name, “CUSTOMER”) == 0) {TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 183 of 287

Data-Maintenance Frame 1 Pseudo-code: Update a table// CUSTOMER// Update the second email address of a CUSTOMER// identified by c_id. Set the ISP part of the customer’s// second email address to “@mindspring.com”// or“@earthlink.com”.

email2 = NULL
len = 0lenMindspring = strlen(“@mindspring.com)
selectemail2 = C_EMAIL_2
from
CUSTOMER
where
C_ID = c_id
len = strlen(email2)
if ( ((len – lenMindspring) >0) and(strcmp(substr(email2,len-lenMindspring,
lenMindspring),”@mindspring.com”) == 0)) {updateCUSTOMER
set
C_EMAIL_2 = substring(C_EMAIL_2, 1,
charindex(“@”,C_EMAIL_2) ) + ‘earthlink.com’
where
C_ID = c_id
} else { /* set to @mindspring.com */updateCUSTOMER
set
C_EMAIL_2 = substring(C_EMAIL_2, 1,
charindex(“@”,C_EMAIL_2) ) + ‘mindspring.com’
where
C_ID = c_id}
} else if (strcmp(table_name, “CUSTOMER_TAXRATE”) == 0) {// CUSTOMER_TAXRATE// Find the customer’s current country tax rate code.
// Calculate cyclically the next tax rate code for the customer’s country.
// Update to the new country tax rate code.
declare old_tax_rate

char(3),

new_tax_rate

char(3),

tax_num

int

selectold_tax_rate = CX_TX_ID

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 184 of 287

Data-Maintenance Frame 1 Pseudo-code: Update a table
from
CUSTOMER_TAXRATE
where
CX_C_ID = c_id and(CX_TX_ID like “US%” or CX_TX_ID like “CN%”)if (left(old_tax_rate,2) = “US”) {if (old_tax_rate = “US5”) {new_tax_rate = “US1”}else {// Change string US<n> to US<n+1> for n=1, 2, 3, 4

tax_num = CODE(right(old_tax_rate,1)) – CODE(“0”) + 1
new_tax_rate = “US” + CHAR(tax_num + CODE(“0”))}else {
if (old_tax_rate = “CN4”) {new_tax_rate = “CN1”}else {// Change string CN<n> to CN<n+1> for n=1, 2, 3

tax_num = CODE(right(old_tax_rate,1)) – CODE(“0”) + 1
new_tax_rate = “CN” + CHAR(tax_num + CODE(“0”))}}updateCUSTOMER_TAXRATEset
CX_TX_ID = new_tax_rate
where
CX_C_ID = c_id and
CX_TX_ID = old_tax_rate} else if (strcmp(table_name, “DAILY_MARKET”) == 0) {// DAILY_MARKET// A security symbol, a day in the month and a// random positive or negative number are passed into// the Data-Maintenance function, when table_name// is DAILY_MARKET. The DM_VOL column in the DAILY_MARKET// table will be updated by adding the random positive or// negative number.
// The rows to be updated are those for the security// whose symbol was passed in, and for that day in the// month that was passed in.
updateDAILY_MARKET
set

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 185 of 287

Data-Maintenance Frame 1 Pseudo-code: Update a table
DM_VOL = DM_VOL + vol_incr
where
DM_S_SYMB = symboland substring ((convert(char(8),DM_DATE,3),1,2) = day_of_month} else if (strcmp(table_name, “EXCHANGE”) == 0) {// EXCHANGE// Other than the table_name, no additional// parameters are used when the table_name is EXCHANGE.
// There are only four rows in the EXCHANGE table. Every// row will have its EX_DESC updated. If EX_DESC does not// already end with “LAST UPDATED “ and a date and time,// that string will be appended to EX_DESC. Otherwise the// date and time at the end of EX_DESC will be updated// to the current date and time.
rowcount = 0
selectrowcount = count(*)
from
EXCHANGE
where
EX_DESC like “%LAST UPDATED%”
if (rowcount == 0) {updateEXCHANGE
set
EX_DESC = EX_DESC + “ LAST UPDATED “ + getdatetime()} else {updateEXCHANGE
set
EX_DESC = substring(EX_DESC,1,
len(EX_DESC)-len(getdatetime())) + getdatetime()}} else if (strcmp(table_name,”FINANCIAL”) == 0) {// FINANCIAL// Update the FINANCIAL table for a company identified by// co_id. That company’s FI_QTR_START_DATEs will be// updated to the second of the month or to the first of// the month if the dates were already the second of the// month.
rowcount = 0
select

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 186 of 287

Data-Maintenance Frame 1 Pseudo-code: Update a tablerowcount = count(*)
from
FINANCIAL
where
FI_CO_ID = co_id andsubstring(convert(char(8),FI_QTR_START_DATE,2),7,2) = “01”if (rowcount > 0) {updateFINANCIAL
set
FI_QTR_START_DATE = FI_QTR_START_DATE + 1 day
where
FI_CO_ID = co_id} else {updateFINANCIAL
set
FI_QTR_START_DATE = FI_QTR_START_DATE – 1 day
where
FI_CO_ID = co_id}} else if (strcmp(table_name, “NEWS_ITEM”) == 0) {// NEWS_ITEM// Update the news items for a specified company.
// Change the NI_DTS by 1 day.
updateNEWS_ITEM
set
NI_DTS = NI_DTS + 1day
where
NI_ID = (selectNX_NI_ID
from
NEWS_XREF
where
NX_CO_ID = @co_id)} else if (strcmp(table_name,”SECURITY”) == 0) {// SECURITY// Update a security identified symbol, increment// S_EXCH_DATE by 1 day.
updateSECURITY
set
S_EXCH_DATE = S_EXCH_DATE + 1day

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 187 of 287

Data-Maintenance Frame 1 Pseudo-code: Update a table
where
S_SYMB = symbol} else if strcmp(table_name,”TAXRATE”) == 0) {// TAXRATE// Update a TAXRATE identified by tx_id. The tax rate’s// TX_NAME will have a substring modified from “ Tax ” to “ tax ”// or from “ tax ” to “ Tax ”, depending on the current value.
tx_name = NULL
selecttx_name = TX_NAME
fromTAXRATE
where
TX_ID = tx_id
if (tx_name like “% Tax %”) {tx_name = replace(tx_name, “ Tax “, “ tax “)} else {tx_name = replace(tx_name, “ tax “, “ Tax “)}
updateTAXRATEset
TX_NAME = tx_name
where
TX_ID = tx_id} else if (strcmp(table_name,”WATCH_ITEM”) == 0) {// WATCH_ITEM// Find the “middle” symbol in the current watch list.
// Find the next symbol in the SECURITY table that is not already in the// current watch list. Update the middle symbol in the current watch// list with the new symbol.
declare cnt

int,

old_symbolchar(15),

new_symbolchar(15)

selectcnt = count(*)// number of rows is [50..150]

from
WATCH_ITEM,
WATCH_LIST

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 188 of 287

Data-Maintenance Frame 1 Pseudo-code: Update a table
where
WL_C_ID = c_id and
WI_WL_ID = WL_ID
cnt = (cnt + 1)/2// calculate “middle” row index// select “middle” row current symbol
selectold_symbol = WI_S_SYMB
from( selectROWNUM,
WI_S_SYMB
fromWATCH_ITEM,
WATCH_LIST
where
WL_C_ID = c_id and
WI_WL_ID = WL_ID andorder by
WI_S_SYMB asc)
whererownum = cnt
select first 1
new_symbol = S_SYMB
fromSECURITY
where
S_SYMB > old_symbol and
S_SYMB not in (select
WI_S_SYMB
fromWATCH_ITEM,
WATCH_LIST
where
WL_C_ID = c_id and
WI_WL_ID = WL_ID)
order by
S_SYMB asc
update
WATCH_ITEM

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 189 of 287

Data-Maintenance Frame 1 Pseudo-code: Update a table
set
WI_S_SYMB = new_symbol
from
WATCH_LIST
where
WL_C_ID = c_id and
WI_WL_ID = WL_ID and
WI_S_SYMB = old_symbol}
commit transaction}

3.3.12The Trade-Cleanup Transaction
The Trade-Cleanup Transaction is used to cancel any pending or submitted trades from the database.
The Sponsor may use EGenTxnHarness to call Trade-Cleanup or may invoke the Transaction by othermeans.
Trade-Cleanup is used to bring the database to a known state before the start of a Test Run.
The Trade-Cleanup Transaction consists of a single Frame. The Trade-Cleanup Transaction may be
implemented using more than one Database Transaction.

3.3.12.1

Trade-Cleanup Transaction Parameters

The inputs to the Trade-Cleanup Transaction are supplied by the Sponsor. The data structures definedin TxnHarnessStructs.h must be used to communicate the input and output parameters.
Trade-Cleanup Interfaces

Module/Data Structure

Transaction Input/Output Structure

TTradesCleanupTxnInput
TTradesCleanupTxnOutput

Frame 1 Input/Output Structure

TTradesCleanupFrame1Input<none>

Trade-Cleanup Transaction Parameters:
Parameter

Directionst_canceled_idINst_pending_id

INst_submitted_id

INtrade_id

IN

Description
Identifier for the “Canceled” trade order status – passed in for ease ofbenchmarking.
Identifier for the “Pending” trade order status – passed in for ease ofbenchmarking.
Identifier for the “Submitted” trade order status – passed in for ease ofbenchmarking.
The trade identifier to be used as the start for handling outstanding submitted
and/or pending limit trades.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 190 of 287

3.3.12.2

Trade-Cleanup Transaction Database Footprint

The Trade-Cleanup Database Footprint is as follows:
Trade-Cleanup Database Footprint
Frame
Table

Column1

TRADE

TRADE_HISTORY
TRADE_REQUEST

T_DTS

ModifyT_ID

Reference

T_ST_ID

ModifyRow(s)Add

Row(s)

Remove

TR_T_ID Reference
Start
CommitTransaction Control

3.3.12.3

Trade-Cleanup Transaction Frame 1 of 1

The database access methods used in Frame 1 are a mixture of References, Modifies, Removes and
Adds.
If EGenTxnHarness is used to invoke the Frame, it controls the execution of Frame 1 as follows:{
invoke (Trade-Cleanup_Frame-1)}
Trade-Cleanup Frame 1 of 1 Parameters:
Parameter

Direction

Description

st_canceled_id

IN

Identifier for the “Canceled” trade order status – passed in for ease ofbenchmarking.

st_pending_id

IN

Identifier for the “Pending” trade order status – passed in for ease ofbenchmarking.

st_submitted_id

IN

Identifier for the “Submitted” trade order status – passed in for ease ofbenchmarking.

trade_idIN

The trade identifier to be used as the start for handling outstanding submitted
and/or pending limit trades.

Trade-Cleanup_Frame-1 Pseudo-code: cancel pending and submitted trades{
start transaction
Declare t_id

TRADE_T

Declare tr_t_id

TRADE_TTPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 191 of 287

Trade-Cleanup_Frame-1 Pseudo-code: cancel pending and submitted trades
Declare now_dts

DATETIME/* Find pending trades from TRADE_REQUEST */declare pending_list for
select
TR_T_ID
fromTRADE_REQUEST
order by
TR_T_ID
open pending_list/* Insert a submitted followed by canceled record into TRADE_HISTORY, mark the tradecanceled and delete the pending trade */do until (end_of_pending_list) {fetch frompending_list
into
tr_t_id
get_current_dts ( now_dts )insert into
TRADE_HISTORY (TH_T_ID, TH_DTS, TH_ST_ID)
values (tr_t_id,// TH_T_ID

now_dts,// TH_DTS

st_submitted_id// TH_ST_ID)
update
TRADE
set
T_ST_ID = st_canceled_id,
T_DTS = now_dts
where
T_ID = tr_t_id
insert into
TRADE_HISTORY (TH_T_ID, TH_DTS, TH_ST_ID

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 192 of 287

Trade-Cleanup_Frame-1 Pseudo-code: cancel pending and submitted trades)
values (tr_t_id,// TH_T_ID

now_dts,// TH_DTS

st_canceled_id// TH_ST_ID)} //end of pending_list/* Remove all pending trades */deletefrom
TRADE_REQUEST/* Find submitted trades, change the status to canceled and insert a canceled record
into TRADE_HISTORY*/
declare submit_list for
select
T_ID
from
TRADE
where
T_ID >= trade_id and
T_ST_ID = st_submitted_id
open submit_list
do until (end_of_submit_list) {fetch from
submit_list
into
t_id
get_current_dts ( now_dts )/* Mark the trade as canceled, and record the time */update
TRADE
set
T_ST_ID = st_canceled_id
T_DTS = now_dts
where
T_ID = t_id
insert into
TRADE_HISTORY (TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 193 of 287

Trade-Cleanup_Frame-1 Pseudo-code: cancel pending and submitted trades
TH_T_ID, TH_DTS, TH_ST_ID)
values (t_id,// TH_T_ID

now_dts,// TH_DTS

st_canceled_id// TH_ST_ID)} //end of submit_list
commit transaction}

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 194 of 287

CLAUSE 4 -- DESCRIPTION OF SUT, DRIVER, AND NETWORK
4.1

Overview
TPC-E is a distillation of an abstraction of a “real-world” OLTP environment. In order to understandwhat TPC-E tests and, as a consequence, what TPC-E does not test, it is necessary to understand thebase “real-world” environment (Clause 4.1.1 Description of Real-World OLTP Environment), theabstraction of that base environment (Clause 4.1.2 Functional Component Abstraction of the RealWorld OLTP Environment) and the distillation of that abstraction (Clause 4.1.3 Distillation of
Functional Components into the TPC-E Environment).

4.1.1

Description of the Real-World OLTP Environment
The figure below shows the “real-world” environment upon which TPC-E is based. Users connect tothe brokerage house over a network using a myriad of possible interface devices (e.g. PCs or handheld
units). The brokerage house is also able to connect via a network to external businesses (e.g. the stock
market exchanges).
Examples ofUser Interfaces
Modeled Business
Workstation
Network

LaptopHand-held

Stock Market
Exchange

Presentation
Services

Application
And
Business Logic
Services

Network

Database
Services

LegendCustomerSponsor Provided

Cell phone

Example ofExternal Business

Stock Market

Figure 4.a - Diagram of the Real-World OLTP Environment
4.1.2

Functional Component Abstraction of the Real-World OLTP Environment
From the diagram of the real-world OLTP environment, the following diagram of the key functional
components can be abstracted.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 195 of 287

Modeled Business

User
Interfaces

Network

Presentation
Services

Application
And
Business Logic
Services

MarketExchange

Network

Database
Services

LegendCustomerSponsor Provided
Stock Market

Figure 4.b - Abstraction of the Functional Components in an OLTP
Environment
A user makes use of some device to connect, via the network, to the business’s presentation services. As
is typical in a Customer-to-Business environment, the presentation layer provides a way for the user tonavigate the available services, select the desired operation, enter data and read results. A practicalexample of this would be a customer using a home PC to connect to a web site to conduct business.
The brokerage house would likewise connect via a network to an external business, such as the market
exchange. As is typical of a Business-to-Business environment, presentation services are not needed.
Rather, data can be exchanged directly without the need for a human-readable format.
Regardless of how the data arrives at the brokerage house, it ultimately will pass through transaction
management functions where connection multiplexing/de-multiplexing occurs; routing may also occur
here as well as other possible functions. The transaction management layer ensures the data will bedelivered to the right business logic code that can perform the requested task.
A critical step in the business logic occurs when the data is handed off to some function or method
implementation for database processing. This method implementation will include Database Interface
code for packaging up the appropriate data and sending it to the database application logic (e.g. stored
SQL procedure) running in the context of the DBMS. The database application logic will then use
DBMS services to perform the necessary tasks, and the results will ultimately be returned “up-stream”
as appropriate.
4.1.3

Distillation of Functional Components into the TPC-E Environment
By design, TPC-E is database-centric. Therefore, even though Presentation Services are an importantpart of a complete Customer-to-Business solution, they have been distilled out of the TPC-E workload.
As a practical matter, Presentation Services often scale out such that a Test Sponsor will configure(replicate) enough servers to run the Presentation Services so they are not a limiting factor for thebenchmark. So, to focus on what is being evaluated and to facilitate ease of benchmarking, Presentation
Services are not a functional component in the test configuration.
In the context of the diagram of the functional components of the target system model, the role of the
Customer is that of a decision maker and data provider (i.e., deciding what transaction to do andsupplying the necessary inputs for that transaction). However, the absence of Presentation Services in
TPC-E leads to some simplifications in the test configuration emulation of the User. The decision
making and data input generation characteristics of the User are still essential, but characteristics of theUser like typing rates and think times are not necessary.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 196 of 287

The role of the User Interface Device (UID) is to accept inputs from the User and send those inputs to
the Presentation Services, and accept outputs from the Presentation Services and display those outputs
to the User. However, TPC-E does not define or require display layouts (since there are no Presentation
Services). Consequently there is no requirement to transmit transaction input and output data in adisplay format. For example, there is no need to send and receive fully formed HTML pages via HTTP;
transaction inputs and outputs may be communicated in a binary format (i.e. by sending C++ data
structures over a socket).
Based on these items and the diagram of the functional components of the target system model, a
diagram for the functional components of the test configuration can be derived. Note that theimplementation of these functional components implies a combination of hardware and software.
Driving and Reporting

SponsorProvided

EGenDriver

CE…

MEE…

DM…

EGenDriverCE

EGenDriverMEE

EGenDriverDM

…CE

…MEE

…DM

TPC DefinedInterfaces

EGenDriver Connector
SponsorProvided

Network

EGenTxnHarness Connector
EGenTxnHarness
SponsorProvided

TPC-E Logic and Frame Calls

TPC DefinedInterface

Frame Implementation
LegendDatabase Interface
Commercial
Product
SponsorProvidedSponsor Provided
TPC Provided

DBMS
Database Logic

Commercial Product
TPC DefinedInterface

Figure 4.c - Functional Components of the Test Configuration
4.1.3.1

Driving & Reporting – Sponsor provided functionality to set up, administer and execute a Test Run,
collect data and generate summary reports. The Sponsor written code must invoke EGenDriverthrough a TPC Defined Interface.

4.1.3.2

CE – Sponsor provided functionality to set up, administer and execute the Customer Emulator. The
Sponsor written code must invoke EGenDriverCE.

4.1.3.3

MEE – Sponsor provided functionality to set up, administer and execute the Market-Exchange
Emulator. The Sponsor written code must invoke EGenDriverMEE.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 197 of 287

4.1.3.4

DM – Sponsor provided functionality to set up, administer and execute the Data-MaintenanceTransaction once a minute. The Sponsor may also provide functionality to call the Trade-Cleanup
Transaction once prior to the start of the run (see description of EGenDriverDM below). The Sponsor
written code must invoke EGenDriverDM.

4.1.3.5

A TPC Defined Interface is a C++ class member which is designed to exchange data (and transfer
execution control) between the Sponsor-provided Driver/SUT code and the TPC-provided Driver/SUT
code. The table in appendix A.14 lists the TPC Defined Interfaces and the associated C++ classes andmember functions.

4.1.3.6

EGenDriver – TPC provided C++ source code that implements essential functionality during a Test
Run. The use of EGenDriver is mandatory. The following are parts of EGenDriver.

4.1.3.7



EGenDriverCE – Customer Emulator that provides the required Transaction Mix and user
input data generation



EGenDriverMEE – Market Exchange Emulator that provides the stock market functionalityand data generation



EGenDriverDM – Data-maintenance functionalities that generates data for and invokes theData-Maintenance Transaction. Also, supplies an interface that can be used by the Sponsor to
invoke the Trade-Cleanup Transaction.

EGenDriver Connector – Sponsor provided functionality that complies with a TPC Defined Interface.
The EGenDriver Connector is invoked from inside EGenDriver through the interface. The
EGenDriver Connector is responsible for sending the EGenDriver generated data to, and receiving thecorresponding resultant data back from, the EGenTxnHarness Connector via the Network. An
example of the hardware and software needed to implement the Connector is:Sponsor written code

An Operating System that provides a socket API and the underlying functionalityThe hardware system the Operating System runs on and the network interface card necessary
to connect to the Network (the network cable coming out of the NIC to connect it to the
Network would not be considered part of the Connector but rather part of the Network).

4.1.3.8

Network – Sponsor provided functionality that must support communication through an industry
standard communications protocol using a physical means. One outstanding feature of the Connector –Network – Connector communication is that it follows the relevant standards and must imply morethan just an application package. It must be possible to have concurrent use of the means by otherapplications. Physical transport of the data is required and the underlying means of this transport must
be capable of operating over arbitrary globally geographic distances. TPC/IP over a local area network
is an example of an acceptable Network implementation.

4.1.3.9

EGenTxnHarness Connector – Sponsor provided functionality responsible for receiving the data sent
from, and sending the appropriate resultant data back to, the EGenDriver Connector via the Network.
The EGenTxnHarness Connector provides the data to, and accepts the resultant data from,
EGenTxnHarness by invoking a TPC Defined Interface. The EGenDriver Connector example
implementation above applies here as well.

4.1.3.10

EGenTxnHarness – TPC provided C++ source code that implements essential functionality during a
Test Run. EGenTxnHarness invokes the Sponsor’s implementations of the Transaction Frames,
providing the necessary inputs and accepting the necessary outputs through a TPC Defined Interface.
The use of EGenTxnHarness is mandatory.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 198 of 287

4.1.3.11

Frame Implementation – Sponsor provided functionality that accepts inputs from, and provides
outputs to, EGenTxnHarness through a TPC Defined Interface. The Frame Implementation and all
down-stream functional components are responsible for providing the appropriate functionality
outlined in the Transaction Profiles (Clause 3.3).

4.1.3.12

Database Interface – Commercially available product used by the Frame Implementation tocommunicate with the Database Server. It is possible that the Database Interface may communicate
with the Database Server over a Network, but this is not a requirement.

4.1.3.13

Database Server – Commercially available product(s). Sponsor provided logic may run in the context
of the Database Server (e.g. a stored SQL procedure). An example of a Database Server is:

4.1.3.14

commercially available DBMS running on a

commercially available Operating System running on a

commercially available hardware system utilizingcommercially available storage

Database Logic – Sponsor written Frame implementation logic (e.g. stored SQL procedure)
Comment: EGenDriver Connector and EGenTxnHarness Connector implementations are allowed toperform modifications to the format of the data provided to them if and only if: such modifications aredone to support differing characteristics of the underlying transport mechanisms. For example,
transporting the data from a big-endian machine to a little-endian machine or from an ASCII
environment to an EBCDIC environment will require changes in the data format.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 199 of 287

4.2

Driver & System Under Test (SUT) Definitions
The diagram of the functional components of the Test System can be leveraged to provide pictorial
definitions of the Driver, SUT, Tier A and Tier B.
Driving and Reporting

Driver

CE…

MEE…

DM…

EGenDriverCE

EGenDriverMEE

EGenDriverDM

…CE

…MEE

…DM

EGenDriver Connector

Mandatory Network
Between Driver and Tier A

EGenTxnHarness Connector

Tier A

System Under Test
(SUT)

TPC-E Logic and Frame Calls
Frame Implementation
LegendSponsor Provided

Database Interface

TPC Provided

Tier B

DBMS

Commercial Product

Database Logic

TPC DefinedInterface

Figure 4.d - Defined Components of the Test Configuration
4.2.1

The Driver – is defined to be all hardware and software needed to implement the Driving & Reporting,
EGenDriver and up-stream Connector functional components.

4.2.2

The use of a Network (as defined in Clause 4.1.3) between the Driver and Tier A is mandatory.

4.2.3

Tier A – is defined to be all hardware and software needed to implement the down-stream Connector,
EGenTxnHarness, Frame Implementation and Database Interface functional components.

4.2.4

Tier B – is defined to be all hardware and software needed to implement the Database Server
functional component. This includes data storage media sufficient to satisfy the initial database
population requirements of clause 2.6.1 and the Business Day growth requirements of clause 6.6.6.4
and clause 6.6.6.5.

4.2.5

System Under Test (SUT) – is defined to be the sum of Tier A and Tier B.

4.2.6

Measured Configuration - See System Under Test.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 200 of 287

Comment: It is possible for the Driver, Tier A and Tier B to share implementation resources. For

example, the software portion of the Driver implementation and the software portion of Tier A may
both run on the same underlying hardware.

4.3

Example Test Configuration Implementations

4.3.1

The following figure shows the physical components that could be assembled to implement a
hypothetical test configuration.
DriverTier B

Tier A

Data
App. Server

Network

Mandatory
Network
betweenDriver andTier A

Data

App. Server
Data

Database ServerApp. Server

System Under Test

Figure 4.e - Sample Component of Physical Test Configuration
4.3.2

The next few figures show some valid variations on the above test configuration and some of the valid
ways for the Driver, Tier A, and Tier B to share common resources.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 201 of 287

Tier A & Tier B

DriverData

Mandatory
Network
betweenDriver andTier A

Data

Data

App. & Database Server

System Under Test
Figure 4.f - Separate Driver with Combined Tier A and Tier B
Driver & Tier A

Tier B

Data
App. Server

Network

Mandatory
Network
betweenDriver andTier A

Data

App. Server
Data

Database ServerApp. Server

System Under Test

Figure 4.g - Driver and Tier A Combined, Separate Tier B
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 202 of 287

Driver, Tier A & Tier B

Data

Mandatory
Network
betweenDriver andTier A

Data

Data

App. & Database Server

System Under Test
Figure 4.h - Combined Driver, Tier A and Tier B

4.4

Further Requirements for SUT and Driver Implementations

4.4.1

Restrictions on the Driver
The purpose of this section is to limit the knowledge (or use of the knowledge by the Driver) of the
SUT, the contents of the database and the transactions. The intent is to encourage Sponsors to develop
Driver implementations independent of the makeup of the System Under Test or its underlying
database and transactions. The restrictions defined in the following clauses are designed to limit theextent that Sponsors can take advantage of the limited nature of TPC-E, the database and transactions.

4.4.1.1

During the Test Run the Sponsor written code to implement the Driver must not:

make decisions based upon the contents of the database (including EGenInputFiles)

provide information to the SUT that results in a performance advantage

4.4.1.2

If customer partitioning in EGenDriverCE is used, the configuration must satisfy the requirements ofClause 6.4.2.

4.4.1.3

The no-peeking-in-the-packet rule: Data predicated routing (based on the content of the packet) in
EGenDriver Connector or EGenTxnHarness Connector is not allowed.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 203 of 287

4.4.1.4

The Sponsor written code executed between EGenDriver (i.e. the following APIs: CESUTInterface,
MEESUTInterface, DMSUTInterface) and the mandatory Network may not make any decision related
to routing, timing, reordering or pacing of that Transaction or any other Transaction based on that
Transaction’s type or input values.
Comment: These restrictions include direct knowledge (e.g., obtained by peeking in the packet) or

implied knowledge (e.g., obtained by card counting, message size, etc.).
4.4.1.5

Any Sponsor written code that sends a market request from the SUT to the Driver (i.e.
SendToMarketInterface) may not make any decisions related to routing, timing, reordering, or pacingof that request or any other request based on that request’s input values.
Comment: These restrictions include direct knowledge or implied knowledge.

4.4.1.6

If routing is done within a Frame Implementation, a transaction monitor must perform the routing (seeClause 3.2.1.9). The Sponsor’s implementation of SendToMarketFromFrame interface is not governed bythis clause but the implementation still must conform to clause 4.4.1.5.

4.4.2

Disclosure of Network Configuration
The Test Sponsor shall describe completely the Network configurations of both the tested services andthe proposed real (target) services which are being represented.

4.4.3

SUT Implementation Limits on Operator Intervention
Systems must be able to run normal operations for at least a Business Day without requiring any
operator intervention to sustain the Reported Throughput.
Comment: Operator intervention is defined as any activity that requires an operator or an individual toperform a function to enable the SUT to continue processing Transactions.
4.4.4

Synchronization of TimeAll of the systems used for the Driver and SUT must have system clocks which are synchronized towithin a tolerance of 10 seconds across all systems. The synchronization must be verified once before
and once after the Test Run.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 204 of 287

CLAUSE 5 -- EGEN
5.1

Overview
EGen is a TPC provided software package designed to facilitate the implementation of TPC-E. EGen
provides:

consistent data generation independent of the underlying environmentTransaction generation and Frame flow control managementproject build and makefile templatesThis clause covers the constraints and regulations governing the use of EGen. For detailed information
on EGen, what features and functionality it provides and how a Test Sponsor is to use those featuresand functionality see Appendix A.

5.2

EGen Terms

5.2.1

EGen is a TPC provided software environment that must be used in a Test Sponsor's implementationof the TPC-E benchmark. The software environment is logically divided into three packages:
EGenProjectFiles, EGenInputFiles, and EGenSourceFiles. The software packages provide
functionality to use: EGenLoader to generate the data used to populate the database, EGenDriver togenerate transactional data and EGenTxnHarness to control frame invocation.

5.2.2

EGenProjectFiles is a set of TPC provided files used to facilitate building the EGen packages in a Test
Sponsor's environments.

5.2.3

EGenInputFiles is a set of TPC provided text files containing rows of tab-separated data, which areused by various EGen packages as “raw” material for data generation.

5.2.4

EGenSourceFiles is the collection of TPC provided C++ source and header files.

5.2.5

EGenLoader is a binary executable, generated by using the methods described in EGenProjectFileswith source code from EGenSourceFiles, including any extensions by a Test Sponsor (see Clause
5.7.4). When executed, EGenLoader uses EGenInputFiles to produce a set of data that represents theinitial state of the TPC-E database.

5.2.6

EGenDriver comprises the following parts:


EGenDriverCE provides the core functionality necessary to implement a Customer Emulator.



EGenDriverMEE provides the core functionality necessary to implement a Market Exchange
Emulator.



EGenDriverDM provides the core functionality necessary to implement the Data-Maintenance
Generator.

5.2.7

EGenDriver provides core transactional functionality (e.g. Transaction Mix and input generation)necessary to implement a Driver.EGenTxnHarness defines a set of interfaces that are used to control
the execution of, and communication of inputs and outputs, of Transactions and Frames.

5.2.8

EGenValidate is a binary executable, generated by using methods described in EGenProjectFiles withsource code from EGenSourceFiles. When executed, EGenValidate uses Sponsor provided input tovalidate that the Sponsor's Measurement Interval had compliant Trade-Results per Load Unit.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 205 of 287

5.2.9EGenLogger logs the initial configuration and any re-configuration of EGenDriver and EGenLoader,and compares current configuration with the TPC-E prescribed defaults.

5.3

Compliant EGen Versions

5.3.1

The TPC Policies Clause 5.3.1 requires that the version of the specification and EGen must match. The
EGen version can be determined by calling the GetEGenVersion function provided in
EGen/src/EGenVersion.cpp file.

5.3.2

EGen is intended to produce correct data. However, it is the Test Sponsor’s responsibility to ensurethat the random distribution of all data values, inputs and Transaction Mix frequencies produced byEGen is compliant with all constraints documented in the specification (e.g. Transaction Mix,
execution rules, population constraints, etc.).

5.3.3

Any existing errors in a compliant version of EGen, as provided by the TPC, are deemed to be incompliance with the specification. Therefore, any such errors may not serve as the basis for acompliance challenge.

5.3.4

EGen is written in ISO C/C++ based on the following standards:


ISO/IEC 9899:1999 Programming Language C

ISO/IEC 14882:2003 Programming Language C++

Failure of a C/C++ compiler to properly compile EGen because of the compiler’s non-conformancewith the above standards does not constitute a bug or error in EGen.
5.3.5

Using EGen within a Compliant Driver
As the EGen code is written C++, there is the capability for sponsors to extend the TPC-provided
classes, while not modifying EGenSourceFiles itself. Furthermore, there is the implicit requirement forSponsors to provide their own methods for some classes in order to produce a working Driver
implementation.
There are two cases which need to be considered:Concrete Classes: These classes (and respective methods) are completely defined and implemented
within EGenSourceFiles

Virtual Classes: These classes (and respective methods) are completely defined and partially
implemented within EGenSourceFiles

In order to preserve the integrity of the benchmark, the following requirements are defined:

5.3.6



Concrete classes must be used as-is. They cannot be sub-classed, overloaded or otherwise
modified.



Virtual classes must be extended by Sponsors, via sub-classing and/or implementation of
missing methods.

Addressing Errors in EGen
If a Test Sponsor must correct an error in EGen in order to publish a Result, the following steps mustbe performed:
1.

The error must be reported to the TPC, following the method described in clause 5.3.7, no later than
the time when the Result is submitted.

2.

The error and the modification used to correct the error must be reported in the FDR, as describedin clause 9.4.5.1.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 206 of 287

3.

The modification used to correct the error must be reviewed by a TPC-Certified Auditor.

Furthermore, the modification and any consequences of the modification may be used as the basis for a
non-compliance challenge.
5.3.7

Process for Reporting Issues with EGen
EGen has been tested on a variety of platforms. None-the-less, it is impossible to guarantee that EGen
is functionally correct in all aspects or will run correctly on all platforms. It is the Test Sponsor's
responsibility to ensure EGen runs correctly in their environment(s).

5.3.7.1

Portability Issues

If a Sponsor believes there is a portability issue with EGen, the Sponsor must:

Document the exact nature of the portability issue.

Document the exact nature of the proposed fix.

Contact the TPC Administrator with the above specified documentation (hard or soft copy is
acceptable) and clearly state that this is an EGen portability issue. The Sponsor must provide
return contact information (e.g. Name, Address, Phone number, Email).

The TPC will provide an initial response to the Sponsor within 7 days of receiving notification of theportability issue. This does not guarantee resolution of the issue within 7 days.
If the TPC approves the request, the Sponsor will be contacted with detailed instructions on how toproceed. Possible methods of resolution include:

The TPC releasing an updated specification and EGen update



The TPC issuing a formal waiver documenting the allowed changes to EGen. In the event a waiveris issued and used by the Sponsor, certain documentation policies apply (see Clause 9.4.5.1).

If the TPC does not approve the request, the TPC will provide an explanation to the Sponsor of why
the request was not approved. The TPC may also provide an alternative solution that would be deemed
acceptable by the TPC.
5.3.7.2

Other Issues

For any other issues with EGen, the Sponsor must:

5.3.8

1.

Document the exact nature of the issue.

2.

Document the exact nature of the proposed fix.

3.

Contact the TPC Administrator with the above specified documentation (hard or soft copy is
acceptable) and clearly state that this is an EGen issue not related to portability. The Sponsor must
provide return contact information (e.g. Name, Address, Phone number, Email).

Submitting EGen Enhancement Suggestions
As a result of using EGen, Test Sponsors may have suggestions for enhancements. To submit asuggestion the Sponsor must:
1.

Document the exact nature of the proposed enhancement

2.

Document any proposed implementation for the enhancement

3.

Contact the TPC Administrator with the above specified documentation (hard or soft copy is
acceptable) and clearly state that this is an EGen enhancement suggestion. The Sponsor must
provide return contact information (e.g. Name, Address, Phone number, Email).

The TPC does not guarantee acceptance of any submitted suggestion. However, all constructive
suggestions will be reviewed by the TPC, and a response will be provided to the Test Sponsor.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 207 of 287

5.4

EGenProjectFilesThe EGenProjectFiles provided by the TPC are meant to be used as a template for Test Sponsors todevelop their EGen environments. Use of EGenProjectFiles is optional.

5.5

EGenInputFiles
Modification of EGenInputFiles provided by the TPC is not permitted.

5.6

EGenSourceFiles
Modification of EGenSourceFiles provided by the TPC is not allowed, except as permitted by clause
5.3.

5.7

EGenLoader

5.7.1

The data for a compliant TPC-E database must be generated by EGenLoader. The version of
EGenLoader used must be compliant with the version of the specification the Result is being publishedunder, as listed in clause 5.3.

5.7.2

It is presumed that EGenLoader produces the correct number of rows for each TPC-E table. However
due to the random nature of the data generated by EGenLoader, the data may not be compliant with
Clause 2 of this specification. In that event the test database is considered invalid.

5.7.3

If EGenLoader generates an empty string, an empty string should be loaded in the database.

5.7.4

If the Test Sponsor extends the loading interface of EGenLoader (as described in Appendix A.6.6), allextension code must be reviewed by a TPC-Certified Auditor. The use of and audit of extension code
must be reported in the Report. The extension code must be reported in the Supporting Files.
Comment: The intent of this clause is to ensure that all data generated by EGenLoader is not modified,other than to support formatting issues of database data types and sorting of the data, while stillallowing Sponsors the ability to customize EGenLoader to specify how the data gets loaded into the
database.

5.8

EGenDriver

5.8.1

All EGenLogger output must be reported in the Supporting Files. If any EGenLogger output contains“NO”, indicating the correct default values were not used, the benchmark Result is not compliant.

5.8.2

Sponsors must use a constructor for each object class (CCE, CMEE, or CDM) that does not have
RNGSEED parameter(s).

5.8.3

Sponsors must ensure that the values provided for the UniqueID parameters to the constructors foreach object group (CCE, CMEE or CDM) are unique within each object group.

5.8.4

The Transaction inputs are generated by the EGenDriverCE, EGenDriverMEE and EGenDriverDM
classes. Each CE, MEE and DM instance must be instantiated using consistent values for some global
inputs, and must use the same values used by all EGenLoader instances during the initial data
generation.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 208 of 287

The contents of EGenInputFiles used by all EGenLoader instances (when building the database) andby all CE, MEE and DM instances (when running against the database) must be the EGenInputFilesfor the version of TPC-E that is used in the benchmark publication.
5.8.5

EGenDriverCE

5.8.5.1

A compliant CE implementation must use EGenDriverCE.

5.8.5.2

If customer partitioning in EGenDriverCE is used, the configuration must satisfy the requirements ofClause 6.4.2.

5.8.6

EGenDriverMEE

5.8.6.1

A compliant MEE implementation must use EGenDriverMEE.

5.8.7

EGenDriverDM

5.8.7.1

A compliant Data-Maintenance Generator must use EGenDriverDM.

5.8.7.2

One, and only one, instance of the Data-Maintenance Generator is required and allowed during a Test
Run.

5.9

EGenTxnHarness

5.9.1

A compliant TPC-E implementation must use EGenTxnHarness.

5.10

EGenValidate

5.10.1

A compliant TPC-E implementation must use EGenValidate to verify a Measurement Interval has
compliant Trade-Results per Load Unit.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 209 of 287

CLAUSE 6 -- EXECUTION RULES & METRICS
6.1

Introduction
This clause defines the execution rules and the methods for calculating the benchmark metric.

6.1.1

Definition of Terms

6.1.1.1

The term Reported refers to an item that is part of the FDR (see Clause 9 -- for detailed requirements).

6.1.1.2

The term Valid Transaction refers to any Transaction for which input data has been sent in full by the
Driver, whose processing has been successfully completed on the SUT and whose correct output data
has been received in full by the Driver.
Comment 1: Transaction errors are not allowed during the Test Run. A Transaction that nevercompletes is considered an error.
Comment 2: A Trade-Order Transaction that requires a rollback that runs successfully and produces thecorrect output is considered a Valid Transaction.
Comment 3: A Transaction that aborts and is retried by the SUT and ultimately completes successfully

and produces the correct output is not an error. A Transaction may not be retried by the Driver.

6.2

Driver Implementation Architectures
Although the use of EGenDriver code is mandatory when implementing a compliant Driver (seeClause 5.2.1), there is still a fair degree of flexibility in the overall Driver architecture. The variations inarchitecture that result from this flexibility have an impact on understanding and interpreting thebenchmark execution rules. Therefore, this section provides an overview of key architectural variations.
These models are examples only and do not represent an exhaustive list. For simplicity, the focus will
be on the CE, but the same principles apply to the MEE as well.

6.2.1

The Simple CE
In its simplest form, the CE has:

A single thread of execution

A single instance of the CCE class (i.e. an EGenDriverCE of size 1)A single blocking Network connection to the SUT

During the Test Run, the CE cycles through a process of calling from Sponsor provided code into
EGenDriverCE code to generate the next Transaction type and the necessary input data, calling fromthe EGenDriverCE code into Sponsor provided code to record the Transaction’s start time, send the
input data to the SUT, wait for the Transaction to execute, receive in the output data from the SUT,
record the Transaction’s end time, and then finally return from the Sponsor code back through the
EGenDriverCE code back to the initial Sponsor code. At this point, the Sponsor may inject an optional
Pacing Delay before repeating the whole process. The following diagram captures this pictorially.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 210 of 287

Customer Emulator–DoTxn()EGenDriverCE
DoTxn()–Generate Txn Type
–Generate Txn Inputs–CESUTInterface::TxnType

CESutInterface /EGenDriver Connector

TxnType()–Record Start Time sTn–Send data to SUT–Wait for Response–Receive data from SUT–Record End Time eTn

LegendSponsor Provided
TPC Provided
Commercial Product
TPC DefinedInterface

Figure 6.a - The Simple CE
6.2.2

The Replicated CE
There are limits to the amount of throughput the Simple CE can generate. So replication of the Simple
CE is permitted. This allows multiple copies of the Simple CE to generate the necessary Nominal
Throughput for any size database. Since there will be multiple instances of the CCE class, this isequivalent to an EGenDriverCE of size N (where N is the number of CCE instances).
The mandatory use of EGenDriverCE’s auto-RNG seeding (see Clause 5.8.2) means that these will not
be exactly identical copies of the Simple CE. Each copy will start off at a different point in the RNG
stream. The following diagram shows the Replicated CE.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 211 of 287

EGenDriverCE

Customer Emulator

EGenDriverCE

CESutInterface /EGenDriver Connector
CESutInterface/

Customer Emulator
EGenDriverCE
EGenDriver Connector–DoTxn()DoTxn()
Customer Emulator
EGenDriverCE
CESutInterface/–DoTxn()DoTxn() –Generate Txn Type
EGenDriver Connector–Generate
Txn
InputsTxn
Type–DoTxn()DoTxn() –Generate
TxnType()–CESUTInterface::TxnType–Generate
Inputs–Generate
TxnTxnType
TxnType()–Record Start Time sTn–CESUTInterface::TxnType–Generate
Txn Inputs–Send data to SUT–CESUTInterface::TxnType

Start Time sTn
TxnType() –Record–Wait for Response–Send data to SUT–RecordStart Timen–ReceivedatasT
from
SUT
–Wait
for Response–Send –Record
data to SUT
End Time eTn–Receive data from SUT–Wait for Response–Record End Time eT–Receive data from SUT n–Record End Time eTn

LegendSponsor Provided
TPC Provided
Commercial Product
TPC DefinedInterface

Figure 6.b - The Replicated CE

6.2.3

The Asynchronous CE
Flexibility can be added into a Sponsor’s CE environment by introducing asynchronicity. There are twoplaces where this can be done.
Between the CESUTInterface code and the EGenDriver Connector code

Between the EGenDriver Connector code and the EGenTxnHarness Connector code

The following sections describe these scenarios in more detail.
6.2.3.1

Asynchronous Transaction Generator

Asynchronicity between the CESUTInterface code and the EGenDriver Connector code is achieved byusing some form of a queue. This allows one thread of execution to act as a Transaction generator for
one or more other Driver threads of execution. In this arrangement, the Transaction generator thread
makes use of EGenDriverCE code to generate the Transactions and their associated inputs. This
information is then placed on a queue. Then a pool of one or more Driver threads of execution candequeue the pre-generated Transactions and send them to the SUT for processing. The following
diagram shows the Asynchronous Transaction Generator.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 212 of 287

EGenDriver Connector

Customer Emulator EGenDriverCE–DoTxn()–Dequeue( Txn )–Record Start Time sTn–Send data to SUT–Wait for Response–Receive data from SUT–Record End Time eTn

CESutInterface

DoTxn()•Generate Txn Type
•Generate Txn Inputs•CESUTInterface::TxnType

TxnType()•Enqueue( Txn )EGenDriver Connector–Dequeue( Txn )–Record Start Time sTn–Send data to SUT–Wait for Response–Receive data from SUT–Record End Time eTn

LegendSponsor Provided
TPC Provided
Commercial Product
TPC DefinedInterface

Figure 6.c – Asynchronous Transaction Generator

When using the Asynchronous Transaction Generator architecture for Customer Initiated andBrokerage Initiated transactions, the following constraints must be met.
Each generator must have a unique queue and there must be one and only one queue per
generator.

Each generator’s queue must be FIFO.



EGenDriver Connector threads of execution must always dequeue from the same queue.

Comment: Although not mandatory, the Asynchronous Transaction Generator architecture is anticipatedto be used with the CMEE class when implementing a Market Exchange Emulator. Note that Clause
4.4.1.4 places constraints on the implementation. For example, while there is no restriction on thenumber of queues the MEE generator may have, Clause 4.4.1.4 requires the queues to be FIFO andprohibits them from being transaction-type based (this would be considered implicit routing).

6.2.3.2

Non-Blocking Driver Threads of Execution

There is a mandatory Network connection between the EGenDriver Connector code and the
EGenTxnHarness Connector code (see Clause 4.1.3.8). The Sponsor can choose whether blocking or
non-blocking Network connections are used. The use of non-blocking Network connections introduces
asynchronicity between the Driver and the SUT. This allows a Driver thread of execution to submit a
new Transaction to the SUT prior to the completion of other Transactions previously submitted by thesame thread. The completion of Transactions may be handled by the initiating thread or by acompletely different thread. The following diagram shows the Non-Blocking Driver.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 213 of 287

Customer Emulator–DoTxn()EGenDriverCE

CESutInterface /EGenDriver Connector

DoTxn()–Generate Txn Type
–Generate Txn Inputs–CESUTInterface::TxnType

TxnType()–Record Start Time sTn–Send data to SUT

LegendAsynchronous Transaction Completion HandlingSponsor Provided•Receive data from SUT

TPC Provided•Record End Time eTn

Commercial Product
TPC DefinedInterface

Figure 6.d – Non-Blocking Driver Threads of Execution

6.2.4

Combinations
Combinations of some or all of the previous architectural variants are possible. For example, an
Asynchronous Transaction Generator could be used with Non-Blocking Driver Threads of Execution.
This architecture could then be replicated multiple times.

6.2.5

Driver Reporting Requirements
The number of EGenDriverMEE and EGenDriverCE instances used in the benchmark must bereported in the Report.

6.3

Transaction Mix
The TPC-E workload is made up of a set of Transactions acting against a database following a specified
Transaction Mix. During the Test Run, the CCE code controls the generation of Brokerage Initiatedand Customer Initiated Transaction types via a card deck methodology designed to satisfy the
specified mix (see CETxnMixGenerator.cpp). The Market Triggered Transactions are not generated by
the CE but arise from asynchronous actions in the MEE.
Since deviations from the specified mix are still possible, it is the Test Sponsor's responsibility to makesure that the following criteria were indeed met for the Measurement Interval in order for the
Measurement Interval to be valid. For the purposes of verifying that these criteria are met any and all
Valid Transactions whose sTn and eTn are both within the Measurement Interval are to be counted.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 214 of 287

6.3.1

Mix Requirements
The following table shows the target mix percentage. The Test Sponsor must show that the actual
percentage obtained for each Transaction type over the entire Measurement Interval is within thespecified Required Range.
Transaction

Target Pct

Required Range

Broker-Volume

4.9%

4.875% – 4.925%

CustomerPosition

13%

12.935% – 13.065%

Market-Feed

1%

0.995% – 1.005%

Market-Watch

18%

17.910% – 18.090%

Security-Detail14%

13.930% – 14.070%

Trade-Lookup

8%

7.960% – 8.040%

Trade-Order

10.1%

10.049% – 10.151%~1% of Trade Orders rollback (see Clause 6.4.1,
rollback is 1 out of each 101 Trade Orders.). 99% of
10.1% is the 10% for Trade Result.

Trade-Result

10%9.950% - 10.050%

There is one Trade-Result per Trade-Order
completed by the MEE, but ~1% of Trade-Order
Transactions rollback at time of initial processing.

Trade-Status

19%18.905% - 19.095%

Trade-Update2%

1.990% - 2.010%

Total

Comment

Each Market-Feed contains entries for 10completed Trade-Results.

100%

Comment: The number of completed Trade-Results is one per non-aborted Trade-Order. However,pending limit orders are delayed until their trigger price is reached. Therefore mix percentages mayvary over short periods of time. Similarly, the number of Market-Feed Transactions is controlled by the
CMEE code to be one for every ten Trade-Results generated. Therefore the mix frequencies may varyover short periods of time. In general though, they will closely follow 1/10th the mix percentage ofTrade-Result.
6.3.2

Required Precision for Mix Percentage Reporting
The Transaction Mix percentages must be reported to the same precision as shown in the Required
Range in the table in Clause 6.3.1.
Computing the mix frequencies actually obtained during the Measurement Interval must be done withat least four decimal places and must be rounded to the nearest three decimal places when reported.
For example, 7.2344 must be reported as 7.234 and 7.2345 must be reported as 7.235

6.3.3

Data-Maintenance
A single Data-Maintenance Transaction must be invoked every sixty seconds. The actual interval
between the executions of two consecutive Transactions must be no less than 58 seconds and no morethan 62 seconds. Each Data-Maintenance Transaction must successfully complete in 55 seconds or less.

6.3.4

Trade-Cleanup
The special Trade-Cleanup Transaction is not part of the Transaction Mix. There are no Response
Time criteria for the Trade-Cleanup Transaction, except that the Transaction must be invoked andfinish before any other type of Transaction can be executed.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 215 of 287

6.4

Transaction Parameters
Each Transaction type has variable inputs. Some of the Transactions have specified percentages (seeDriverParamSettings.h) for the possible values of these inputs. During the Test Run, the EGenDrivercode controls the generation of the values for theses inputs using a random number generator in amanner designed to satisfy the specified percentage (see CETxnInputGenerator.cpp). However sincedeviations from the specified percentage are still possible, it is the Test Sponsor's responsibility tomake sure that the following criteria were indeed met for the Measurement Interval in order for the
Measurement Interval to be valid. For the purposes of verifying that these criteria are met, inputs forany and all Valid Transactions, whose sTn and eTn are both within the Measurement Interval and are
to be counted.

6.4.1

Input Value Mix Requirements
The following table shows the target input value percentages. The Test Sponsor must show that theactual percentage obtained for each input type over the entire Measurement Interval is within thespecified Required Range.
Input Parameter

Value

Target Pct Required Range

Customer-Position
by_tax_id

1

50%

48% to 52%

get_history

1

50%

48% to 52%

Watch list

60%

57% to 63%

Account ID

35%

33% to 37%

Industry5%4.5% to 5.5%11%

0.9% to 1.1%

130%

28.5% to 31.5%230%

28.5% to 31.5%

330%

28.5% to 31.5%

410%9.5% to 10.5%

Transactions requested by a third party

10%

9.5% to 10.5%

Security chosen by company name and issue

40%

38% to 42%

Market-Watch

Securities chosen by

Security-Detailaccess_lob

Trade-Lookup

frame_to_execute

Trade-Order

type_is_margin

1

8%7.5% to 8.5%

roll_it_back

1~1%

0.94% to 1.04% (*)

is_lifo

1

35%

33% to 37%

100

25%

24% to 26%

200

25%

24% to 26%

400

25%

24% to 26%

800

25%

24% to 26%

TMB

30%

29.7% to 30.3%

trade_qty

trade_type

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 216 of 287

TMS

30%

29.7% to 30.3%

TLB

20%

19.8% to 20.2%

TLS

10%

9.9% to 10.1%

TSL

10%

9.9% to 10.1%

1

33%

31% to 35%

2

33%

31% to 35%

334%

32% to 36%

Trade-Update

frame_to_execute(*) Comment: The ratio of aborted trades to completed trades is 1/100 or 1%, so the ratio of aborted
trades to all trades is 1/101 or only ~1%. The actual expected percentage is closer to 0.99%, which is
why the range of acceptable values is 0.94% to 1.04% (not 0.95% to 1.05%), since this range is centeredon the expected 0.99% value.
6.4.2

Customer Partitioning
More than one instance of the CE may be executing simultaneously. The CE instances may bepartitioned by C_ID (customer identifier).

6.4.2.1

Configuration Requirements



The C_ID sub-range for a given EGenDriverCE instance must be a contiguous set of C_IDs.



The minimum C_ID of the sub-range must be the starting C_ID for a Load Unit.



The minimum size of the sub-range of C_IDs is 5,000.

The size of the sub-range of C_IDs must be an integral number of the Load Unit size.

The size of the sub-range of C_IDs does not have to be the same for each CE instance.

In addition, when C_ID partitioning is used, the EGenDriverCE code will ensure that:

C_ID values are chosen from the entire Configured Customer range 50% of the time.



C_ID values are chosen from the provided partitioned customer sub-range 50% of the time.

Comment: For example, assume a database with 60,000 Configured Customers, four (4) CE instances.

The first two instances will use 20,000 customers and the remaining two instances will use 10,000
customers.

6.4.2.2

Instance 1 would be configured to use iMyStartingCustomerId of 1, iMyCustomerCount of 20,000,
and iPartitionPercent of 50%.

Instance 2 would be configured to use iMyStartingCustomerId of 20,001, iMyCustomerCount of
20,000, and iPartitionPercent of 50%.

Instance 3 would be configured to use iMyStartingCustomerId of 40,001, iMyCustomerCount of
10,000, and iPartitionPercent of 50%.

Instance 4 would be configured to use iMyStartingCustomerId of 50,001, iMyCustomerCount of
10,000, and iPartitionPercent of 50%.

Runtime Validation Test

At initialization time for each CE instance, record the partition’s starting customer and partition countof customers supported by this partitioned CE instance. From this information, derive a uniquePartition Range number “r”. All CE instances with the same starting customer and partition countmust be assigned the same “r”.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 217 of 287

During a Test Run, for each CE instance and each started CE Transaction (one whose sTn time has
been assigned), the Driver needs to record enough information to determine after a Test Run thenumber of CE Transactions started from each CE instance during each 30-second time interval.
After a Test Run, when the location and duration of the Measurement Interval has been determined,
process the recorded CE sTn information and perform the following calculations for each nonoverlapping 30-second time interval “t” wholly within the Measurement Interval:
1.

For all CE instances in each Partition Range “r” within each 30-second time interval “t”, count the
number of CE Transactions started (sTn assigned). Call this count Cr,t.

2.

Divide Cr,t by the number of Load Units (LUs) in Partition Range “r”. Call this normalized value
Nr,t.

3.

Compute the “average CE driving rate per Load Unit across the entire database” At by summing all
Cr,t and dividing by the total number of Load Units in the database.

4.

Count the number of Nr,t values that do not satisfy At * 0.95 <= Nr,t <= At * 1.05. Call this count Dt.

5.

Call the total number of Partition Ranges R. If Dt / R > 0.05, then consider time interval “t” to havefailed the test and set Ft to 1; otherwise, set Ft to 0.

Sum the Ft across all values of “t”. Call this value S.
Call the number of 30-second time intervals in the Measurement Interval T.
The Measurement Interval must meet the following requirement:

S / T <= 0.05.

6.5

Response Time and Pacing Delays

6.5.1

Response Time6.5.1.1

The Response Time (RT) is defined by:
RTn = eTn - sTn
where:
sTn and eT n are measured at the Driver;sTn =time measured before the first byte of input data of the Transaction is sent by the Driverto the SUT; andeTn =time measured after the last byte of output data from the Transaction is received by the
Driver from the SUT.
Comment: The resolution of the time stamps used for measuring Response Time must be at least 0.01

seconds.

6.5.1.2

During the Measurement Interval, at least 90% of each Transaction type must have a Response Timeless than or equal to the constraint specified in the table below.
Transaction

90% Response Time
Constraint

Broker-Volume

3 sec.

Customer-Position

3 sec.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 218 of 287

6.5.1.3

Market-Feed

2 sec.

Market-Watch

3 sec.

Security-Detail

3 sec.

Trade-Lookup

3 sec.

Trade-Order

2 sec.

Trade-Result

2 sec.

Trade-Status

1 sec.

Trade-Update

3 sec.

The following diagram illustrates where Response Time’s are measured for each type of Transaction.
Time stamps are taken on the Driver.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 219 of 287

Driver

System Under Test (SUT)

Data
Maintenance

Brokerage
House

sT
DM

DM
eT

Customer
Emulator

MW

BV
CP

sT

TS
TU

CP

TL
SD

BV

MW

TS

TL
eT

TU

SD

sT
TO

TO
eT

OrdersMarketExchange
Emulator

Asynch. Send
To Market
Interface

Limit
Order

Triggered
Limit
OrdersProcesssT

MarketOrder

Trade
Confirmation
TR

TR
ACK

TickereT

Limit
OrdersTicker
sT
MF

MF
eT

ACK

Figure 6.e - Measuring Response Time6.5.1.4

Over the Measurement Interval, the average Response Time for each type of Transaction that is partof the Transaction Mix must not be longer than the 90th percentile Response Time for that Transaction.

6.5.1.5

The Data-Maintenance Transaction does not have average and 90th percentile Response Timerequirements. Instead, each Data-Maintenance Transaction must successfully complete in 55 seconds
or less.

6.5.1.6

There are no Response Time criteria for the Trade-Cleanup Transaction. It must complete successfully
before a Test Run can start and thus before any other type of Transaction can be executed.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 220 of 287

6.5.2

Dispatch Time and Pacing Delay

6.5.2.1

Each EGenDriverCE thread of execution calling the EGenDriver Connector interface creates asequence of Transactions, defined chronologically as { T1, T2, … Tn }. Within each sequence, theDispatch Time of Transaction n is defined as follows:

for the Non-Blocking Driver Thread architecture (see 6.2.3.2)
For n=1: DTn = 0

For n>1: DTn = (sTn – sTn-1)

for all other architectures in Clause 6.2


For n=1: DTn = 0

For n>1: DTn = (sTn – eTn-1)

Where sTn and eTn are defined in Clause 6.5.1.1

6.5.2.2

The Dispatch Time must be less than (or equal) to 1 second during the Measurement Interval.

6.5.2.3

Pacing Delay is defined as the total time injected into the Dispatch Time (DTn) that is intended todecrease the rate at which Transactions are submitted to the SUT.
The Pacing Delay can be adjusted by the Test Sponsor to control the rate at which Transactions are
submitted to the SUT in order to meet the requirements of Clause 6.7.1.
Comment: The value of the Pacing Delay may vary during Steady State and may vary between different

instances of the CCE class.

6.6

Test Run

6.6.1

Definition of Terms

6.6.1.1

The term Test Run refers to the entire period of time during which Drivers submit and the SUT
completes Transactions other than Trade-Cleanup. A Test Run is subdivided into the three consecutive
and non-overlapping time periods of Ramp-up, Steady State and Ramp-down.

6.6.1.2

The term Ramp-up refers to the period of time from the start of the Test Run to the start of SteadyState.

6.6.1.3

The term Steady State refers to the period of time from the end of the Ramp-up to the start of the
Ramp-down.

6.6.1.4

The term Ramp-down refers to the period of time from the end of Steady State to the end of the Test
Run.

6.6.1.5

The term Measurement Interval refers to the period of time during Steady State chosen by the Test
Sponsor to compute the Reported Throughput.

6.6.1.6

The term Business Day refers to a period of eight hours of transaction processing activity.

6.6.1.7

The performance of the SUT is defined to be Sustainable if the performance over a given period oftime (computed as the average throughput over that time) shows no significant variations.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 221 of 287

6.6.2

Database Content

6.6.2.1

Prior to the first Test Run, the initial database must satisfy Clause 2.6.1. Prior to any Test Run, thedatabase must satisfy Clause 2.4 and Clause 2.6.2.
Comment: Clause 2.6.2 defines cardinality changes as Transactions are executed against the database. If

no Transactions have been executed, then initial cardinalities of Clause 2.6.1 apply.
6.6.2.2

At the start of a Test Run the database must not contain any pending or submitted trades. This must be
accomplished either by using a database in its initially populated state or by executing the TradeCleanup Transaction prior to the start of the Test Run.

6.6.2.3

The only changes (unless otherwise directed by an Auditor) that can be made to the content of the TPCE database tables between the initial population and a valid Test Run must be performed by therunning of Valid Transactions, as defined in this specification.

6.6.3

Sustainable Performance

6.6.3.1

During Steady State the throughput of the SUT must be Sustainable for the remainder of a BusinessDay started at the beginning of the Steady State.

6.6.3.2

Some aspects of the benchmark implementation can result in rather insignificant but frequentvariations in throughput when computed over somewhat shorter periods of time. To meet the
Sustainable throughput requirement, the cumulative effect of these variations over one Business Day
must not exceed 2% of the Reported Throughput.
Comment: This requirement is met when the throughput computed over any period of one hour, sliding

over the Steady State by increments of ten minutes, varies from the Reported Throughput by no morethan 2%.
6.6.3.3

Some aspects of the benchmark implementation can result in rather significant but sporadic variationsin throughput when computed over some much shorter periods of time. To meet the Sustainablethroughput requirement, the cumulative effect of these variations over one Business Day must notexceed 20% of the Reported Throughput.
Comment: This requirement is met when the throughput level computed over any period of ten minutes,

sliding over the Steady State by increments one minute, varies from the Reported Throughput by no
more than 20%.
6.6.3.4

Any resources or components required by the SUT to meet the Sustainable performance requirements
must be configured at all time during the Test Run.
Comment 1: An example of a non-compliant configuration would be one where the database log file isassigned to a heterogeneous device starting with a high performance drive and overflowing on aslower drive, achieving better performance during the first few hours of Steady State than during theremainder of the Business Day.
Comment 2: An example of a compliant implementation would be one where the database log file isassigned to a homogeneous device large enough to hold the log over a complete checkpoint cycle andconfigured to be reused over each subsequent checkpoint cycles, achieving a Sustainable throughput
during Steady State and for the remainder of the Business Day.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 222 of 287

6.6.4

Steady State

6.6.4.1

All work or events that must be performed at regular intervals by the SUT during Steady State mustoccur in full at least once between the start of Steady State and the start of the Measurement Interval.
(For example see Clauses 6.6.5.3 and 6.3.3).

6.6.4.2

The duration of Steady State is set by the Sponsor and must be sufficient to:Include a compliant Measurement Interval,

Provide sufficient evidence, at the discretion of the Auditor, that the Sustainable performancerequirement is met,

6.6.5

Measurement Interval

6.6.5.1

The Measurement Interval must be a minimum of two hours and must occur entirely during SteadyState.

6.6.5.2

For the purposes of calculating reported Transaction statistics all Transactions and only thoseTransactions whose sTn and eTn are within the Measurement Interval are used.

6.6.5.3

During the Measurement Interval, the database contents (excluding the transaction log) stored on
Durable Media cannot be more than 15 minutes older than any Committed state of the database.
Comment: This may mean that Database Management Systems implementing traditional checkpoint

algorithms may need to perform checkpoints twice as frequently (i.e. every 7.5 minutes) in order toguarantee that the 15 minute requirement is met.
6.6.5.4

All threads of execution that perform CE Transactions during the Measurement Interval must:

Perform at least one Transaction prior to the start of the Measurement IntervalPerform at least one Transaction after the end of the Measurement Interval

Creating, starting, stopping, deleting threads of execution that perform CE Transactions is not
permitted during the Measurement Interval.
6.6.6

Database Growth

6.6.6.1

The resources or components configured on the SUT to support executing the Transaction Mix at theReported Throughput during the period of required Sustainable performance (see Clause 6.6.3) mustallow for the resulting increase in the size of the DBMS data files (referred to as Data Growth) and the
DBMS log files (referred to as Log Growth).

6.6.6.2

Initial Database Size is measured after the database is initially loaded with the data generated by
EGenLoader. Initial Database Size is any space allocated to the test database which is used to store a
database entity (e.g. a row, an index, Database Metadata), or used as formatting overhead by the data
manager.

6.6.6.3

The total storage space in the DBMS data files can be decomposed into the following:Free Space, which includes any space allocated to the test database and available for future use. It
includes all database storage space not already used to store a database entity (e.g., a row, an index,
Database Metadata) or not already used as formatting overhead by the DBMS.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 223 of 287



Growing Space, which includes any space used to store existing rows from the Growing Tables
and their associated User-Defined Objects. It includes all database storage space that is added tothe test database as a result of inserting a new row in the Growing Tables, such as row data, index
data and other overheads such as index overhead, page overhead, block overhead, and table
overhead.



Fixed Space, which includes any other space used to store static information and indices. It
includes all database storage space allocated to the test database which does not qualify as either
Free Space or Growing Space.
Comment: While cardinality does not change for non-Growing Tables, it is possible that some FixedSpace storage could increase for other reasons. If the computed increase for the Business Day forany such object would be greater than the 5% cardinality increase already imposed on nonGrowing Table objects by Clause 2.3.9, then the larger computed storage increase must be usedinstead of the 5% increase.
6.6.6.4

The Data Growth must be computed based on the Test Run as follows:

The measured Growing Space before the Test Run is recorded.

The Test Run is executed in full.



The measured Growing Space after the Test Run is recorded.

The Data-Space-per-Trade-Result is computed as the total increase in Growing Space over the Test
Run divided by the total number of Trade-Result Transactions completed during the Test Run.

The Data Growth is computed by multiplying the Data-Space-per-Trade-Result by the Reported
Throughput and by the duration of the required Sustainable performance:o6.6.6.5

Data Growth = Data-Space-per-Trade-Result * tpsE * Business Day duration in seconds

The Log Growth must be computed based on the Test Run as follows:

The space used in the database log file before the Test Run is recorded.

The Test Run is executed in full.



The space used in the database log file after the Test Run is recorded.

The total increase in the used for database log space is divided by the number of Trade-Result
Transactions completed during the Test Run, giving the Log-Space-per-Trade-Result.



The Log-Space-per-Trade-Result is multiplied by the Reported Throughput and by the durationof the required Sustainable performance to compute the Log Growth as follows:o Log Growth = Log-Space-per-Trade-Result * tpsE * Business Day duration in seconds

6.6.6.6

60-Day Data Space
Storage must be priced for sufficient space to store and maintain the data and User-Defined Objects
generated during a period of 60 Business Days at the Reported Throughput called the 60-Day Period.
The 60-Day Space must be computed as:
60-Day Space = Initial Database Size + (60 * Data Growth)
The calculation of Data Growth is described in clause 6.6.6.4.

6.6.7

Continuous Operation Requirement
Within the Measured Configuration, there must be sufficient On-Line storage to support:

The initial database population (see Clause 2.6) and all User-Defined Objects present during
the Test Run.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 224 of 287



An additional Business Day’s Data Growth and Log Growth at the Reported Throughput.
The methods to calculate the Data Growth and the Log Growth are described in Clauses 6.6.6.3
and 6.6.6.5.

Comment: The requirement to support a Business Day of recovery log data can be met with storage on

any Durable Media if all data required for recovery from failures listed in Clause 7.5 are On-Line andmeet the Sustainable performance requirements of Clause 6.6.3.
6.6.8

Performance & Database Size

6.6.8.1

To keep throughput proportional to database size, the Measured Throughput must be within a certain
range of performance based on the database size.

6.6.8.2

The Nominal Throughput of the TPC-E benchmark is defined to be 2.00 Transactions-Per-Second-E(tpsE) for every 1000 customer rows in the Configured Customers.

6.6.8.3

Another way of expressing the Nominal Throughput is by using a Scale Factor. The Scale Factor is thenumber of required customer rows per single Transactions-Per-Second-E (tpsE). The Scale Factor for
Nominal Throughput is 500.

6.6.8.4

The Measured Throughput is computed as the total number of Valid Trade-Result Transactions
within the Measurement Interval divided by the duration of the Measurement Interval in seconds.

6.6.8.5

The number of Load Units configured must be equal to the number of Load Units actually accessed
during the Test Run.

6.7

Required Reporting

6.7.1

Reported Throughput

6.7.1.1

The Performance Metric reported by TPC-E is the Reported Throughput. The name of the metric used
for the Reported Throughput of the SUT is tpsE. The value of this metric is based on the Measured
Throughput and is bound by the requirements of Clause 6.7.1.2.

6.7.1.2

If the Measured Throughput is between 80% and 100% of the Nominal Throughput, then theReported Throughput is set to the Measured Throughput, rounded down to two decimal places.
Otherwise, if Measured Throughput exceeds the Nominal Throughput, but not by more than 2%, themeasurement may be used, but the Reported Throughput must be set to the Nominal Throughput. As
a result, the Measured Throughput can be as much as 2% greater than the Reported Throughput. If the
Measured Throughput is not within these bounds, then the measurement is invalid and may not bereported.
Comment 1: For example, for a database size of 5000 customers, the nominal performance is 10.00 tpsE.

A measurement run with throughput between 10.00 tpsE and 10.20 tpsE would be reported as 10.00
tpsE. A measurement run with throughput between 8.00 tpsE and 10.00 tpsE would be reported as that.
A measurement run with throughput lower than 8.00 tpsE, or higher than 10.20 tpsE, is invalid for the
database size and must not be reported.
Comment 2: To increase the level of throughput that can be reported, the number of Configured

Customers in the database must be increased. To decrease the level of throughput that can be reported,
the number of Configured Customers in the database must be decreased. Either of these two actions
requires building a new database.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 225 of 287

6.7.2

Test Run Graph
A graph of the Trade-Results per second averaged over one minute versus elapsed wall clock timemeasured in minutes must be reported for the entire Test Run. The x-axis represents the elapsed timefrom the Test Run start. The y-axis represents the total number of Trade-Result Transactions thatcomplete within each one-minute interval divided by 60. A plot interval size of 1 minute must be used.
The Ramp-up, Steady State, Measurement Interval, and Ramp-down must be identified on the graph.
The Test Run Graph must be reported in the Report.

Figure 6.f - Example of the Test Run Graph
6.7.3

Primary Metrics

6.7.3.1

To be compliant with the TPC-E standard and the TPC’s Fair Use Policies and Guidelines, all public
references to TPC-E Results for a configuration must include the following components which will beknown as the Primary Metrics.


The TPC-E Reported Throughput as expressed in tpsE. This is known as the Performance Metric.



The TPC-E total 3-year pricing divided by the Reported Throughput is price/tpsE. This is also
known as the Price/Performance Metric (See Clause 8 -- ).

The date when all products necessary to achieve the stated performance will be available (stated asa single date on the Executive Summary Statement). This is known as the Availability Date (SeeClause 9.2.1.1).

When the optional TPC-Energy standard is used, the additional primary metric, expressed as
watts/tpsE, must be reported. In addition, the requirements of the TPC-Energy Specification,
located at www.tpc.org, must be met.

6.7.4

EGenValidate Results

6.7.4.1

Each Load Unit must do approximately the same number of Trade-Results during the Measurement
Interval. This requirement must be demonstrated by passing the EGenValidate test and providing
these results in the Supporting Files. EGenValidate is TPC provided code. A Sponsor must generate
the EGenValidate binary executable for their environment.

6.7.4.2

When the Sponsor runs EGenValidate they must provide the following inputs:TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 226 of 287



number of Configured Customers

the standard deviation of the number of Trade-Results performed for each Load Unit during the
Measurement Interval (see Clause 6.6.5.2)

 (n  n )standard deviation =2

i(# LU  1)

where ni = the number of Trade-Results completed for Load Unit i during the Measurement
Interval
The precision required for the standard deviation is three decimal digits to the right of the decimal
point, rounded up if necessary.

6.7.4.3the number of seconds in the Measurement Interval

the Measured Throughput rate recorded during the Measurement Interval

EGenValidate does the following:1.

Reads the input values.

2.

Uses EGen code to simulate up to 10,000 runs on a TPC-E database for that number of Configured
Customers. The program calculates the average number and standard deviation of Trade-Results
per Load Unit during the Measurement Interval.

3.

Prints out “Passed!” if the maximum calculated standard deviation across the 10,000 simulated runs
is larger than or equal to the standard deviation for the Measurement Interval. Otherwise “Failed!”
is printed.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 227 of 287

CLAUSE 7 -- TRANSACTION AND SYSTEM PROPERTIES (ACID)
7.1

ACID Properties

7.1.1

The ACID (Atomicity, Consistency, Isolation, and Durability) properties of transaction processing
systems must be supported by the System Under Test during the running of this benchmark.

7.1.2

It is the intent of this section to define the ACID properties informally and to specify a series of tests
that must be performed to demonstrate that these properties are met.

7.1.3

No finite series of tests can prove that the ACID properties are fully supported. Passing the specified
tests is a necessary, but not sufficient, condition of meeting the ACID requirements. However, forfairness of reporting, only the tests specified here are required and must appear in the Report for thisbenchmark.
Comment: These tests are intended to demonstrate that the ACID principles are supported by the SUT

and enabled during the performance Test Run. They are not intended to be an exhaustive quality
assurance test.
7.1.4

The configuration needed to insure full ACID properties must be enabled during the Test Run. Thisapplies to both the database (including TPC-E tables and User-Defined Objects) and the Database
Session(s) used to execute the ACID tests and the Test Run.
Comment 1: The term “configuration” includes all database properties and characteristics that can be

externally defined; this includes but is not limited to configuration and initialization files,
environmental settings, SQL commands and stored procedures, loadable modules and plug-ins. For
example, if the SUT relies on Undo/Redo Logs, then logging must be enabled for all Transactions,
including those that do not include rollback in the Transaction Profile.
Comment 2: When this benchmark is implemented on a distributed system, tests must be performed toverify that Transactions that are processed on two or more nodes satisfy the ACID properties.
7.1.5

Although the ACID tests do not exercise all Transaction types of this workload, the ACID properties
must be satisfied for all Transactions.

7.1.6

Test Sponsors reporting TPC Results may perform ACID tests on any one system for which Results
have been submitted, provided that they use the same software executables (e.g. Operating System,
database manager, transaction programs). For example, this clause would be applicable when Results
are reported for multiple systems in a product line. However, the Durability tests described in Clauses
7.5.7 and 7.6.3.5 must be run on all the systems that are measured. All FDRs must identify the systems
that were used to verify ACID requirements and full details of the ACID tests conducted and results
obtained.

7.2

Atomicity Requirements

7.2.1

Atomicity Property Definition
The System Under Test must guarantee that Database Transactions are atomic; the system will either
perform all individual operations on the data, or will ensure that no partially completed operations
leave any effects on the data.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 228 of 287

7.2.2

Atomicity Tests
Perform a market Trade-Order Transaction with the roll_it_back flag set to 0. Verify that the appropriate
rows have been inserted in the TRADE and TRADE_HISTORY tables.
Perform a market Trade-Order Transaction with the roll_it_back flag set to 1. Verify that no rows
associated with the rolled back Trade-Order have been added to the TRADE and TRADE_HISTORY
tables.

7.3

Consistency Requirements

7.3.1

Consistency Property Definition
Consistency is the property of the Application that requires any execution of a Database Transaction
to take the database from one consistent state to another.

7.3.1.1

A TPC-E database when first populated by EGenLoader must meet these consistency conditions.

7.3.1.2

If data is replicated, as permitted under Clause 2.3.4, each copy must meet the consistency conditions
defined in Clause 7.3.2.

7.3.2

Consistency Conditions
Three consistency conditions are defined in the following clauses. Explicit demonstration that theconditions are satisfied is required for all three conditions.

7.3.2.1

Consistency condition 1

Entries in the BROKER and TRADE tables must satisfy the relationship:
B_NUM_TRADES = count(*)
For each broker defined by:(B_ID = CA_B_ID) and (CA_ID = T_CA_ID) and (T_ST_ID = “CMPT’).
7.3.2.2

Consistency condition 2

Entries in the BROKER and TRADE tables must satisfy the relationship:
B_COMM_TOTAL = sum(T_COMM)
For each broker defined by:(B_ID = CA_B_ID) and (CA_ID = T_CA_ID) and (T_ST_ID = “CMPT’).
7.3.2.3

Consistency condition 3

Entries in the HOLDING_SUMMARY and HOLDING tables must satisfy the relationship:
HS_QTY = sum(H_QTY)
For each holding summary defined by:(HS_CA_ID = H_CA_ID) and (HS_S_SYMB = H_S_SYMB).
7.3.3

Consistency Tests
The three consistency conditions must be tested after initial database population and after any Business
Recovery tests.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 229 of 287

7.4

Isolation Requirements

7.4.1

Isolation Property Definition

7.4.1.1

Given a Transaction T1 and a concurrently executing Transaction T2, the following phenomena (P0 toP3) are defined as they occur in T1.


P0 (“Dirty Write”) - Transaction T2 modifies (or inserts) data element R. Then, before T2 performs
a COMMIT, Transaction T1 starts and is able to modify (or delete) data element R and is
subsequently able to perform a COMMIT.
Comment: T2 may execute additional database operations based on the state it left data element R in,

potentially compromising the consistency of the data.
P1 (“Dirty Read”) - Transaction T2 modifies (or inserts) data element R. Then, before T2 performs a
COMMIT, Transaction T1 starts, reads data element R and is able to obtain the state of the data
element as changed by T2. Subsequently, T2 is able to perform a ROLLBACK.
Comment: T1 may execute additional database operations based on a state of data element R thathas been rolled back and is considered to have never existed, potentially compromising theconsistency of the data.
P2 (“Non-repeatable Read”) - Transaction T1 reads data element R. Then, before T1 performs a
COMMIT, Transaction T2 starts, modifies (or deletes) data element R and performs a COMMIT.
Subsequently, T1 repeats the read of data element R and is able to obtain the state of the data
element as changed by T2.
Comment: Prior to discovering the modified (or deleted) state of data element R, T1 may haveexecuted additional database operations based on a state of data element R that is considered to be
no longer correct, potentially compromising the consistency of the data.
P3 (“Phantom Read”) - Transaction T1 reads a set of data elements that satisfy some <search
condition>. Then, before T1 performs a COMMIT, Transaction T2 starts and inserts (or deletes) one
or more data elements that satisfy the <search condition> used by T1. Subsequently, T1 repeats theinitial read with the same <search condition> and is able to obtain a different set of data elements
than the initial set.
Comment: Prior to discovering the larger (or smaller), set of data elements, T1 may have executed

additional database operations based on a set of data elements that is considered to no longer
match the <search condition>, potentially compromising the consistency of the data.
7.4.1.2

The isolation property of a Transaction is the level to which it is isolated from the actions of otherconcurrently executing Transactions. The table below, arranged from least (L0) to most (L3) restrictive,
defines four isolation levels based on which phenomena must not occur.

Isolation Level

Phenomena

7.4.1.3

P0

P1

P2

P3

L0

Must not occur

Is possible

Is possible

Is possible

L1

Must not occur

Must not occur

Is possible

Is possible

L2

Must not occur

Must not occur

Must not occur

Is possible

L3

Must not occur

Must not occur

Must not occur

Must not occur

During the Test Run, each TPC-E Transaction must provide a level of isolation from Arbitrary
Transactions that is at least as restrictive as the level defined in the table below:

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 230 of 287

TPC-E Transaction

Isolation Level

Trade-Result

L3

Market-Feed
Trade-Order
Trade-Update

L2

Broker-Volume
Customer-Position
Data-MaintenanceMarket-Watch
Security-Detail
Trade-Lookup
Trade-StatusL1

7.4.1.4

During the Test Run the SUT must allow concurrent execution of Arbitrary Transactions.

7.4.1.5

During the Test Run, the data read by each TPC-E Transaction must be no older than the most recently
Committed data at the time the Transaction started.

7.4.1.6

Systems that implement Transaction isolation using a locking and/or versioning scheme must
demonstrate compliance with the isolation requirements by executing the tests described in Clause
7.4.2.

7.4.1.7

Systems that implement Transaction isolation using techniques other than a locking and/or versioning
scheme may require different techniques to demonstrate compliance with the isolation requirements. It
is the responsibility of the Test Sponsor, in collaboration with the Auditor, to define those techniques,to implement them, to execute them as a demonstration of compliance with the isolation requirements
and to provide sufficient details in the FDR to support the assertion that the isolation requirements
were met.

7.4.2

Isolation Tests
The following isolation tests are designed to verify that the configuration and implementation of the
System Under Test provides the Transactions with the required isolation levels defined in Clause
7.4.1.3.

7.4.2.1

P3 Test in Read-Write

This test demonstrates that a read-write Trade-Result Transaction is protected against the Phantom
phenomenon P3 when executing concurrently with another read-write Trade-Result Transaction. The
second Trade-Result Transaction (Session S4 below) plays the role of an Arbitrary Transaction that isinserting a row into a range of the HOLDING_SUMMARY table which has been accessed by the first
Trade-Result Transaction (Session S3 below).
For the purpose of this test, the two Trade-Result Transactions must be instrumented to record hs_qty
after returning from Frame 1. In addition, the Trade-Result Transaction executed by S3 must be able torepeat the execution of Frame 1 and to be able to pause before starting the execution of Frame 2.
Using four Sessions, S1 to S4, the following steps are executed in order:
1.

From S1, select an acct_id. Using an ad hoc read-only transaction, find a symbol that does not have acorresponding row in the HOLDING_SUMMARY table for the selected acct_id and perform acommit.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 231 of 287

2.

From S1, request and successfully complete a Trade-Order for the acct_id and symbol selected in step
1. Record the trade_id assigned to this new trade.

3.

From S2, request and successfully complete another Trade-Order for the acct_id and symbol used instep 2. Record the trade_id assigned to this new trade.

4.

From S3, request a Trade-Result for the trade_id from step 2. Pause between Frame 1 and Frame 2.
Record hs_qty and verify that it is set to zero.

5.

From S4, request a Trade-Result for the trade_id from step 3. Verify that it completes Frame 1 andstarts execution of Frame 2. Record hs_qty and verify that it is set to zero.
Case A, if S4 stalls in Frame 2, then rolls back, while S3 completes:
6A. From S3, repeat the execution of Frame 1 and pause again between Frame 1 and Frame 2.
Record hs_qty and verify that it set to zero.
7A. Resume execution of S3 at Frame 2. Verify the successful completion of the remaining Frames.
8A. Verify that S4 rolled back.
Case B, if S4 completes (perhaps after stall) and S3 rolls back:
6B. Verify that S4 completes the execution of Frame 2 and of the remaining Frames.
7B. Verify that S3 rolled back.
Case C, if S4 stalls in Frame 1 (Invalid):
6C. If this case occurs, the test is invalid. To properly test protection against phantom reads,
Session S4 must get to the point in Trade-Result Frame 2 where a row is inserted into
HOLDING_SUMMARY. The Trade-Result Transaction used for S4 may need to be modified toprevent it from blocking in Frame 1. For example, it may be executed at the lower isolation level ofan Arbitrary Transaction.

Comment 1: This P3 test is successful if either Case A or B is followed. It fails if Case C occurs. Other
valid possibilities may exist (e.g., both S3 and S4 could fail), but if both S3 and S4 record hs_qty = 0 fromexecution of Frame 1, then at most one of these Sessions may complete normally and commit theTransaction. The intent of this test is to demonstrate that in all circumstances when S3 repeats the readon the HOLDING_SUMMARY table after S4 has inserted (or attempted to insert) a new row for theselected acct_id and symbol, there is still no qualifying row found by S3.
Comment 2: This isolation test creates one or more new holdings. Subsequently executing the P2 Test in

Read-Write (see Clause 7.4.2.2) for the same selected acct_id and symbol can result in closing thepositions created during the execution of this test.
7.4.2.2

P2 Test in Read-Write

This test demonstrates that a read-write Trade-Result Transaction is protected against the Nonrepeatable Read phenomenon P2 when executing concurrently with another read-write Trade-Result
Transaction. The second Trade-Result Transaction (Session S4 below) plays the role of an Arbitrary
Transaction that is updating a row in the HOLDING_SUMMARY table which has been read by the
first Trade-Result Transaction (Session S3 below).
For the purpose of this test, the two Trade-Result Transactions must be instrumented to record hs_qty
after returning from Frame 1. In addition, the Trade-Result Transaction executed by S3 must be able torepeat the execution of Frame 1 and to be able to pause before starting the execution of Frame 2.
Using four Sessions, S1 to S4, the following steps are executed in order:
1.

From S1, select an acct_id. Using an ad hoc read-only transaction, find a symbol that has acorresponding row in the HOLDING_SUMMARY table for the selected acct_id, record the HS_QTY
for that holding and perform a commit.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 232 of 287

2.

From S1, request and successfully complete a Trade-Order for the acct_id and symbol selected in step
1. Record the trade_id assigned to this new trade.

3.

From S2, request and successfully complete another Trade-Order for the acct_id and symbol used instep 2. Record the trade_id assigned to this new trade.

4.

From S3, request a Trade-Result for the trade_id from step 2 and pause between Frame 1 and Frame
2. Record hs_qty and verify that it is equal to HS_QTY from step 1.

5.

From S4, request a Trade-Result for the trade_id from step 3. Verify that it completes Frame 1 andstarts execution of Frame 2. Record hs_qty and verify that it is equal to HS_QTY from step 1.
Case A, if S4 stalls in Frame 2, then rolls back, while S3 completes:
6A. From S3, repeat the execution of Frame 1 and pause again between Frame 1 and Frame 2.
Record hs_qty and verify that it is equal to HS_QTY from step 1.
7A. Resume execution of S3 by invoking Frame 2. Verify the successful completion of theremaining Frames.
8A. Verify that S4 rolled back.
Case B, if S4 completes (perhaps after stall) and S3 rolls back:
6B. Verify that S4 completes the execution of Frame 2 and the remaining Frames.
7B. Verify that S3 rolled back.
Case C, if S4 stalls in Frame 1 (Invalid):
6C. If this case occurs, the test is invalid. To properly test protection against the Non-repeatable
Read phenomenon P2, Session S4 must get to the point in Trade-Result Frame 2 where a row is
updated in HOLDING_SUMMARY. The Trade-Result Transaction used for S4 may need to bemodified to prevent it blocking in Frame 1. For example, it may be executed at the lower isolationlevel of an Arbitrary Transaction.

Comment: This test is successful if either Case A or B is followed. It fails if Case C occurs. Other valid

possibilities may exist (e.g., both S3 and S4 could fail), but if both S3 and S4 record the same hs_qty
value from execution of Frame 1, then at most one of these Sessions may complete normally andcommit the Transaction. The intent of this test is to demonstrate that in all circumstances when S3
repeats the read on the HOLDING_SUMMARY table for the selected acct_id and symbol, the row foundand value is the same as in Step 1.
7.4.2.3

P1 Test in Read-Write

This test demonstrates that a read-write Trade-Result Transaction is protected against the dirty-readphenomenon P1 when executing concurrently with another read-write Trade-Result Transaction. For
the purpose of this test the Trade-Result Transaction must be instrumented to record se_amount after
returning from Frame 5 and to be able to pause in Frame 6 just prior to committing.
Using three Sessions, S1 to S3, the following steps are executed in order:
1.

From S1, request a Customer-Position for a selected cust_id, complete the Transaction and record
the set of resulting acct_id[] and cash_ball[].

2.

From S1, request and successfully complete a Trade-Order from an acct_id selected from the set
recorded in step 1, for a given symbol and with a type_is_margin set to 0. Record the trade_id
assigned to this new trade.

3.

From S1, request and successfully complete another Trade-Order for the same acct_id but a different
symbol than that used in step 2, and with a type_is_margin set to 0. Record the trade_id assigned tothis new trade.

4.

From S2, request a Trade-Result for the trade_id from step 2. Before invoking Frame 6, record
se_amount, then invoke Frame 6 and pause before committing.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 233 of 287

5.

From S3, request a Trade-Result for the trade_id from step 3. The Transaction may pause or fail orbe temporarily blocked from fully executing. If it reaches the start of Frame 6, record se_amount,then invoke Frame 6. If it reaches the end of Frame 6, pause before committing.

6.

From S2, proceed with committing and successfully completing the Transaction. Record theresulting acct_bal.

7.

From S3, depending on how the Transaction behaved at the end of step 5:
If it reached the pause in Frame 6, allow it to proceed and verify that it Committed and completed
successfully.
If it was blocked before the end of Frame 5, verify that it was released, completed Frame 5,
recorded se_amount, executed Frame 6, Committed and completed successfully.
If it failed and was forced to rollback, repeat the Trade-Result request with the same trade_id input
parameter. Verify that the Trade-Result executes in full, records se_amount at the start of Frame 6,
commits at the end of Frame 6 and completes successfully.

8.

7.4.2.4

From S3, record the resulting acct_bal and verify that it is equal to cash_bal[] from step 1 (for theacct_id chosen in step 2) plus the sum of the se_amount outputs for the two Trade-Results.

P1 Test in Read-Only

This test demonstrates that the read-only Customer-Position Transaction is protected against the dirtyread phenomenon P1 when executing concurrently with the read-write Trade-Result Transaction. For
the purpose of this test the Trade-Result Transaction must be instrumented to be able to pause in
Frame 6 just prior to committing.
Using four Sessions, S1 to S4, the following steps are executed in order:
1.

From S1, request a Customer-Position for a selected cust_id, complete the Transaction and record
the set of resulting acct_id[] and cash_bal[].

2.

From S1, request and successfully complete a Trade-Order where the associated acct_id input
matches one of the acct_id[] recorded in step 1 and type_is_margin is 0. Record the trade_id assigned
to this new trade.

3.

From S2, request a Trade-Result for the trade_id from step 2 and then pause in Frame 6 before
committing.

4.

From S3, request a Customer-Position for the cust_id selected in step 1. The Transaction may
complete or fail or be temporarily blocked from fully executing.

5.

From S2, proceed with committing and successfully completing the Trade-Result Transaction. Record
the resulting acct_bal.

6.

From S3, depending on how the Customer-Position Transaction behaved at the end of step 4:
If it completed, record the set of resulting acct_id[] and cash_bal[] and verify that the cash_bal for theacct_id used in step 2 is unchanged from step 1.
If it was blocked, verify that it has now completed, record the set of resulting acct_id[] and cash_bal[]and verify that the cash_bal for the acct_id used in step 2 matches the acct_bal from step 5.
If it failed, proceed to the next step.

7.

From S4, request a Customer-Position for the cust_id selected in step 1, complete the Transaction,
record the set of resulting acct_id[] and cash_bal[] and verify that the cash_bal for the acct_id used instep 2 has changed from step 1 and reflects the amount of the trade completed in step 5 (bymatching acct_bal from step 5).

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 234 of 287

7.5

Durability Requirements
No system provides complete data protection under all possible types and/or combinations of failures.
However, data protection against any Single Point of Failure is commonly expected. Therefore, theintent of this clause is to ensure that the SUT has no unrecoverable Single Points of Failure. The
required data protection is satisfied by the SUT persisting certain data across certain types of failures.
This clause provides details on:Which data must persistWhich types of failures must be protected against

Which steps to follow for the testing/demonstration

Which results must be disclosed

Comment: The limited nature of the tests described in this clause must not be interpreted to allow otherunrecoverable Single Points of Failure.
7.5.1

Definition of Commit
The concept of “commit” has to do with delineating the successful completion of an atomic unit ofwork. The following definition will be leveraged to focus the scope of which data must be persisted by
the SUT.
Commit: a control operation that:

Is initiated by a unit of work (a Transaction)

Is implemented by the DBMS

Signifies that the unit of work has completed successfully and all tentatively modified data areto persist (until modified by some other operation or unit of work)

Upon successful completion of this control operation both the Transaction and the data are said to be
Committed.
7.5.2

Definition of Vulnerable Storage Component
The SUT is composed of many different individual components; each of which represents a Single
Point of Failure. However, the individual failure of many of these components (e.g. the monitor on aclient machine) would not compromise the SUT’s ability to persist the necessary data. The following
definition will be leveraged to focus the scope of which storage components within the SUT represent
potential vulnerabilities.
Vulnerable Storage Component – any Field Replaceable Unit (FRU) within the SUT that:

Has volatile storage (is not Durable Media)

Participates in implementing the Commit control operation

Example: Assume an implementation like the one in Clause 4.3.1:

7.5.3



The Tier B CPU registers and caches, main memory, I/O controllers with caches used for the
Undo/Redo Log and Durable Media with caches used for the Undo/Redo Log are considered
to participate in implementing Commit operations.



The Tier A CPU registers and caches, main memory and I/O controllers with caches are notconsidered to participate in implementing Commit operations.

Definition of Single Point(s) of FailureThis clause lists various types of failures that can occur within the SUT. This list will be leveraged tofocus the scope of failures the SUT must protect against.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 235 of 287

Any single item covered here is defined to be a Single Point of Failure; when two or more items arebeing discussed, the term Single Points of Failure is used.
7.5.3.1

Loss of Processing

This failure covers an instantaneous interruption in processing Commit control operations (e.g. systemcrash / system hang) that requires a system reboot to recover. This implies an immediate abnormal
system shutdown that requires loading a fresh copy of the Operating System from the boot device. It
does not necessarily imply loss of volatile memory
7.5.3.2

Loss of Vulnerable Storage Component

The failure of a Vulnerable Storage Component means that the data it contained is lost. The failure
may be caused by a loss of power to the Vulnerable Storage Component or because of a failure
internal to the Vulnerable Storage Component that renders the whole Vulnerable Storage
Component inoperable.
7.5.3.3

Loss of All External Power to the SUTThis failure covers the loss of all external power to the SUT for an indefinite period of time. This must
include at least all portions of the SUT that contain Vulnerable Storage Component and/or process
Commit control operations.
7.5.4

Definition of Durable / Durability
The SUT must provide Durability as defined in this clause.
Durable / Durability: In general, state that persists across failures is said to be Durable and an
implementation that ensures state persists across failures is said to provide Durability. In the context
of the benchmark, Durability is more tightly defined as the SUT’s ability to ensure all Committed data
persist across any Single Point of Failure.

7.5.5

Durability Testing Rules and Guidelines
The intent of this clause is to cover specific rules and special-case guidelines.

7.5.5.1

Durability Throughput Requirements

All Durability tests must meet the following requirements:

7.5.5.2

Be performed with the same number of Configured Customers and Driver load used for the
Measurement Interval.

Be in Steady State.

Satisfy the Response Time constraints in Clause 6.5.1.2.

Satisfy the Transaction Mix requirements listed in Clause 6.3.1.



Be at or above 95% of the Reported Throughput with no errors.

Match all Driver and SUT configuration settings used during the Measurement Interval.

Roll-forward recovery from an archive database copy (e.g., a copy taken prior to the run) using
Undo/Redo Log data is not acceptable as the recovery mechanism in the case of failures listed in
Clauses 7.5.3.1, 7.5.3.2 and 7.5.3.3. Note that “checkpoints”, “control points”, “consistency points”, etc.
of the database taken during a run are not considered to be archives.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 236 of 287

7.5.5.3

Instantaneous Failures

Single Points of Failure must be induced instantaneously without any foreknowledge given to the
SUT.
Comment: Reactive actions initiated within the SUT as a result of an Instantaneous Failure are notconsidered foreknowledge.
7.5.5.4

Simulated Failures

A Single Point of Failure may be simulated if the effects on the SUT are identical to those of the actual
occurrence of the Single Point of Failure.
7.5.5.5

Combined Failures

A single test may be used to evaluate Durability across multiple Single Points of Failure if theintegrity of the evaluation is not compromised when compared to evaluating each Single Point ofFailure with a separate test.
Example: Assume a Test Sponsor would like to combine two Single Points of Failure in a single test.
The test is started and ramps up to a state that satisfies the Durability Throughput Requirements. The
Test Sponsor now induces the first Single Point of Failure.


If after inducing the first Single Point of Failure the SUT continues to operate at a level thatsatisfies the Durability Throughput Requirements the Test Sponsor may go ahead and induce
the second Single Point of Failure since the integrity of the evaluation of the second Single
Point of Failure has not been compromised.

However, if inducing the first Single Point of Failure causes the SUT’s performance to decline
such that the Durability Throughput Requirements are no longer met, inducing the second
Single Point of Failure would no longer be a compliant demonstration. The integrity of theevaluation of the second Single Point of Failure has been compromised since the SUT is nolonger operating at a level that satisfies the Durability Throughput Requirements.

Lastly, assume inducing the first Single Point of Failure causes the SUT’s performance todecline such that the Durability Throughput Requirements are no longer met. Since the SUT
is allowed to continue running and is able to regain a level of performance that satisfies the
Durability Throughput Requirements. At this point, the Test Sponsor may go ahead andinduce a second Single Point of Failure since the integrity of the evaluation of the second
Single Point of Failure has not been compromised.

Comment: This example focused on Durability Throughput Requirements when evaluating whether
combining multiple Single Points of Failure into a single test was compliant. There may be othercriteria that must be considered when evaluating if a particular combination of Single Points of Failure
into a single test is compliant.
7.5.5.6

Multiple Identical Single Points of Failure

If the SUT contains multiple identical Single Points of Failure as defined in Clause 7.5.3 that perform
identical benchmark functions, successful demonstration of Durability for one instance is sufficient;
there is no requirement to repeat the demonstration for all the other instances unless directed to do soby the Auditor.
This exemption from testing multiple identical instances does not apply when demonstrating
Durability for Clause 7.5.3.3.
Example – Loss of Processing: In configurations where more than one instance of an Operating
System performs an identical benchmark function, Durability for the failure in Clause 7.5.3.1 must becompleted on at least one such instance.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 237 of 287

Example – Loss of Vulnerable Storage Component: Assume an implementation that contains 4 disk
controllers, each with write-back caching enabled, configured into 2 mirrored pairs. Further assume
that each pair of controllers is configured with the same number and types of drives.


If the drives for each controller pair are configured identically with respect to their contents (i.e.
same mixture and proportion of database tables) then these 2 controller pairs are identical
Single Points of Failure. As such, demonstrating Durability across one pair (by failing one of
the controllers in the pair) is sufficient; there is no need to demonstrate Durability across thesecond pair as well.

If however, one pair of controllers had disks configured with database tables and the othercontroller pair had disks configured with database logs, then Durability must be demonstrated
across each pair since they are performing different benchmark functions and therefore are not
identical Single Point of Failure.

Example – Loss of All External Power to the SUT: Assume a database cluster with multiple identicalnodes where each node contains Vulnerable Storage Components. Performing a power failure test forjust one node is not sufficient because the exemption from testing multiple identical instances does not
apply when demonstrating Durability for Clause 7.5.3.3.
7.5.5.7

Multi-OS Interconnects as a Single Point of Failure

If multiple instances of an Operating System manage data that is maintained as a single image for thebenchmark applications and those instances are connected via a physical medium other than an
integrated bus (e.g. bus extender cable, high speed LAN, or other connection methods between themultiple instances of the Operating System that could be vulnerable to a loss from physicaldisruption), the instantaneous interruption of this communication is included as an item that must be
tested in conjunction with Clause 7.5.3.1. Interruption of one instance of redundant connections isrequired.
Comment: It is not the intention of this clause to require interruption of communication to disk towers
or a disk subsystem where redundancy exists.
7.5.5.8

Simultaneity of External Power Loss Across Multiple Components

When demonstrating Durability for the loss of all external power to the SUT (per Clause 7.5.3.3), allportions of the SUT that are required to be included must lose power simultaneously. For ease ofbenchmarking, up to three seconds is allowed between the time power is lost to the first component
and the time power is lost to the last component.
7.5.5.9

UPSs – Protecting Against Loss of All External Power

UPSs may be included in the Priced Configuration as a means of protecting the SUT from the loss of
all external power (per Clause 7.5.3.3). The general idea is along the lines of the following:The power grid supplying the data center goes offline thus causing a loss of external power tothe SUT. The UPSs provide power to the SUT seamlessly.

Without operator intervention:o The SUT detects the loss of power.
o The SUT initiates an orderly process for handling the situation (e.g. a controlled system
shutdown).
o Any/all relevant data that are not on Durable Media are transferred to Durable Media.
o The orderly handling process completes successfully.

The expectation is that the SUT is now protected for the indefinite time period required by Clause
7.5.3.3. The risk of UPSs and/or batteries running out of power is no longer a concern because all
relevant data are on Durable Media.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 238 of 287

In general, simply pricing the UPSs is sufficient; there is no requirement to demonstrate the above
scenario unless directed to do so by an Auditor.
7.5.5.10

UPSs – Sizing of Priced UPSs

The priced UPSs must be sized to provide power for at least 30 minutes of uninterrupted operations.
The 30-minute power consumption of the protected portion of the SUT must be either:

7.5.5.11

Measured during a Test Run or

A calculation of the 30-minute power requirements (in watts) for the protected portion of the
SUT multiplied by 1.4.

UPSs – Representing Single Points of Failure

When pricing UPSs as protection against Clause 7.5.3.3, each UPS is defined to be a new Single Pointof Failure. As such, the SUT must provide Durability across the independent failure of each UPS.
7.5.6

Definition of Recovery Terms

7.5.6.1

Database Recovery

Database Recovery: the process of recovering the database from a Single Point of Failure system
failure.
7.5.6.2

Database Recovery – Start Time

The start of Database Recovery is the time at which database files are first accessed by a process thathas knowledge of the contents of the files and has the intent to recover the database or issue
Transactions against the database.
Comment: Access to files by Operating System processes that check for integrity of file systems orvolumes to repair damaged data structures does not constitute the start of Database Recovery.
7.5.6.3

Database Recovery – End TimeThe end of Database Recovery is the time at which database files have been recovered.
Comment: The database will usually report this time in its log files.
7.5.6.4

Database Recovery Time

Database Recovery Time: the duration from the start of Database Recovery to the point when databasefiles complete recovery.
7.5.6.5

Application Recovery

Application Recovery: the process of recovering the business application after a Single Point ofFailure and reaching a point where the business meets certain operational criteria.
7.5.6.6

Application Recovery – Start Time

The start of Application Recovery is the time when the first Transaction is submitted after the start of
Database Recovery.
7.5.6.7

Application Recovery – End TimeThe end of Application Recovery is the first time, T, after the start of Application Recovery at which
the following conditions are met:

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 239 of 287



The one-minute average completed Trade-Results per second (i.e. average completed TradeResults per second over the interval from T to T + 1 minute) is greater than or equal to 95% ofReported Throughput



The 20-minute average completed Trade-Results per second (i.e. average completed TradeResults per second over the interval from T to T + 20 minutes) is greater than or equal to 95% ofReported Throughput.

Comment: When considering the 20—minute interval, the average completed Trade-Results per
second for the first minute must be at or above 95% of Reported Throughput (as required by the firstbullet above). However, some number of the subsequent 19 one-minute average completed TradeResults per second values may drop below 95% of Reported Throughput. This is acceptable as long as
the overall 20-minute average completed Trade-Results per second is not less than 95% of Reported
Throughput (as required by the second bullet above).
7.5.6.8

Application Recovery Time

Application Recovery Time: The elapsed time between the start of Application Recovery and the endof Application Recovery (see Clause 7.5.6.5).
7.5.6.9

Business Recovery

Business Recovery: the process of recovering from a Single Point of Failure and reaching a point
where the business meets certain operational criteria.
7.5.6.10

Business Recovery TimeBusiness Recovery Time: the elapsed period of time between start of Business Recovery and end of
Business Recovery (see Clause 7.5.6.9).
Comment: Single Points of Failure can be very disruptive to business processing, therefore it isimperative for businesses to recover from these failures as quickly as possible. There are many
database configuration parameters and practices that directly affect the performance of the DBMS and
its recovery time from a Single Point of Failure. However, while it is recognized that boot times for
systems vary greatly, boot parameters have little to no affect on the performance of the DBMS. For thisreason, server boot times are not included as part of the Business Recovery Time.
7.5.7

Durability Test Procedure for Single Points of Failures
1.

Determine the current number of completed trades in the database by running:
select count(*) as count1 from SETTLEMENT.

2.

Start Test Run 1 by submitting Transactions and ramp up to the Durability Throughput
Requirements (as defined in Clause 7.5.5.1) and satisfy those requirements for at least 20 minutes.

3.

Induce one or more of the Single Points of Failure failures, from Clause 7.5.3.

4.

If appropriate for the test configuration, stop submitting Transactions.

5.

If necessary, restart the SUT (may necessitate a full reboot).

6.

Note the time when Database Recovery starts (see Clause 7.5.6.2), either automatically or manuallyby an operator.

7.

When Database Recovery ends, note the time. This may occur during the following steps (seeClause 7.5.6.3).

8.

Start Test Run 2 or continue Test Run 1 submitting Transactions and note this time as the start ofApplication Recovery (see Clause 0). Ramp up to 95% of Reported Throughput.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 240 of 287

Comment: If there is a time gap between the end of Database Recovery and the start ofApplication Recovery and if Drivers and Transactions need to be started again (not justcontinued), then the Trade-Cleanup Transaction may be executed during this time gap.
9.

Note the end of Application Recovery as defined in Clause 7.5.6.7.

10. Terminate the Driver gracefully.
11. Verify that no errors were reported by the Driver during steps 7 through 10. The intent is to ensurethat an end-user would not see any adverse effects (aside from availability of the application andpotentially reduced performance) due to the SUT failure and subsequent Business Recovery.
12. Retrieve the new number of completed trades in the database by running:
select count(*) as count2 from SETTLEMENT
13. Compare the number of completed Trade-Result Transactions on the Driver to (count2 – count1).
Verify that (count2 - count1) is greater or equal to the aggregate number of successful Trade-Result
Transaction records in the Driver log file for the runs performed in step 2 and step 8. If there is aninequality, the SETTLEMENT table must contain additional records and the difference must be lessthan or equal to the maximum number of Transactions which can be simultaneously in-flight fromthe Driver to the SUT. This number is specific to the implementation of the Driver andconfiguration settings at the time of the crash.
Comment: This difference must be due only to Transactions which were Committed on the
System Under Test, but for which the output data was not returned to the Driver before thefailure.
14. Verify consistency conditions as specified in Clause 7.3.3.
15. Calculate Business Recovery Time as the sum of Application Recovery Time and Database
Recovery Time, if those times do not overlap. If Application Recovery begins before Database
Recovery is complete, Business Recovery Time is the time elapsed between the beginning of
Database Recovery and the end of Application Recovery.
7.5.8

Required Reporting for Durability

7.5.8.1

Business Recovery TimeThe Business Recovery Time must be reported on the Executive Summary Statement and in theReport. If the failures described in Clauses 7.5.3.1, 7.5.3.2 and 7.5.3.3 were not combined into one
Durability test (usually powering off the Database Server during the run), then the Business Recovery
Time for the failure described for instantaneous interruption is the Business Recovery Time that must
be reported in the Executive Summary Statement. All the Business Recovery Times for each test
requiring Business Recovery must be reported in the Report.
7.5.8.2

Business Recovery Time Graph

A graph of the Trade-Results per second averaged over one minute versus elapsed time must bereported in the Report for the run portions of the Business Recovery tests, prepared in accordance withthe following conventions:

The x-axis represents the maximum of the elapsed times for the two runs described in Clause
7.5.7 steps 2 and 8The y-axis represents the throughput (computed as the total number of Trade-Result
Transactions that complete within each one-minute interval divided by 60)

A plot interval size of 1 minute must be used

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 241 of 287

7.6



The y-axis data for both runs is to be overlaid on a single graph, with the end times of each run
clearly markedFor graphing purposes, time 0 is defined as follows:

For the run outlined in 7.5.7 step 2, time 0 is defined as the point in time where the first
Transaction is issued to the database

For the run outlined in 7.5.7 step 8, time 0 is defined as the point in time where Database
Recovery begins

For graphing purposes, the end of the run is defined as follows:

For the run outlined in 7.5.7 step 2, the end of the run is the time at which the failure is induced(see 7.5.7 step 3)For the run outlined in 7.5.7 step 8, the end of the run is the time at which the Application
Recovery has ended successfully (see 7.5.7 step 8)For the run outlined in 7.5.7 step 8, if any time elapses between the end of Database Recovery
and the start of Application Recovery, this time should be ignored and the two periods should
be presented adjacent on the graph.



A horizontal line at 95% of the Reported Throughput must also be plotted across the graph

Data Accessibility Requirements
The System Under Test must be configured to satisfy the requirements for Data Accessibility detailed
in this clause. Data Accessibility is demonstrated by the SUT being able to maintain database
operations with full data access after the permanent irrecoverable failures of any single Durable
Medium containing database tables, recovery log data, or Database Metadata. Data Accessibility tests
are conducted by inducing failures of Durable Media within the SUT. The failures of Clause 7.6.3 test
the ability of the SUT to maintain access to the data. The specific failures addressed in Clause 7.6.3 aredefined sufficiently significant to justify demonstration of Data Accessibility across such failures.
However, the limited nature of the tests listed must not be interpreted to allow other unrecoverable
single points of failure.

7.6.1

Definition of Terms

7.6.1.1

Data Accessibility: The ability to maintain database operations with full data access after thepermanent irrecoverable failure of any single Durable Medium containing database tables, recovery
log data, or Database Metadata.

7.6.1.2

Durable Medium: a data storage medium that is inherently non-volatile such as a magnetic disk ortape. Durable Media is the plural of Durable Medium.

7.6.2

Data Accessibility Throughput Requirements
All Data Accessibility tests must meet the following requirements:
Be performed with the same number of Configured Customers and Driver load used for the
Measurement IntervalBe in Steady State

Satisfy the Response Time constraints in Clause 6.5.1.2.

Satisfy the Transaction Mix requirements listed in Clause 6.3.1.



Be at or above 95% of the Reported Throughput with no errors

Match all Driver and SUT configuration settings used during the Measurement Interval
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 242 of 287

7.6.3

Failure of Durable MediaThe failures detailed in this clause affect the access of data from Durable Media. The following
requirements are also known as the Data Accessibility requirements.

7.6.3.1

The SUT must maintain database access to data on Durable Media during and after a permanent andirrecoverabla failure of a single Durable Medium containing database tables, recovery log data, or
Database Metadata. The Test Sponsor must also restore the Durable Medium environment to its prefailure condition, while maintaining database access to the data on Durable Media.

7.6.3.2

Durable Media are inheritly non-volatile and are typically magnetic disks using replication (RAID-1
mirroring) or other form of protection (RAID-5, et.al.) to guarantee access to the data during a Durable
Medium failure. Volatile media such as memory can also be used if the volatile media can ensure thetransfer of data automatically, before any data is lost, to an inherently non-volatile medium after the
failure of external power independently of reapplication of external power.
Comment 1: A configured and priced Uninterruptible Power Supply (UPS) is not considered external

power.
Comment 2: Memory can be considered a Durable Medium if it can preserve data long enough to satisfy

the requirements stated above, for example, if it is accompanied by an Uninterruptible Power Supply,
and the contents of memory can be transferred to an inherently non-volatile medium during the failure.
Note that no distinction is made between main memory and memory performing similar permanent or
temporary data storage in other parts of the system (e.g., disk controller caches). If main memory isused as a Durable Medium, then it must be considered as a potential single point of failure. A sample
mechanism to survive single Durable Medium failure is mirrored Durable Media. If memory is the
Durable Medium and mirroring is the mechanism used to ensure Durability, then the mirrored
memories must be independently powered.
7.6.3.3

The Data Accessibility tests (aka. Non-catastrophic failures) must meet the Data Accessibility
Throughput Requirements of Clause 7.6.2.

7.6.3.4

Redundancy Levels

The redundancy levels refer to the level of guarantee for data access given a single failure among thedata storage components. The SUT must implement one of the following Redundancy Levels:Redundancy Level One (Durable Media Redundancy): Guarantees access to the data on Durable
Media when a single Durable Media failure occurs.
Comment: The intent of this redundancy level is to test the ability of the Durable Media

environment to survive the failure of a single Durable Medium and continue processing requests
from the Operating System and/or DBMS.
Example: The Sponsor has implemented RAID-1 (mirroring) on the disks within an enclosure. The

Sponsor must maintain access to the data on the remaining disks despite the induced failure of asingle disk.
Redundancy Level Two (Durable Media Controller Redundancy): Includes Redundancy Level
One and guarantees access to the data on Durable Media when a single failure occurs in thestorage controller used to satisfy the redundancy level or in the communication media between thestorage controller and the Durable Media.
Comment: The intent of this redundancy level is to test the ability of the implementation to survive

the failure of a storage controller responsible for implementing Redundancy Level One.
Example: If Redundancy Level One is satisfied by implementing RAID-5 protection within a disk

enclosure, then Redundancy Level Two would be tested by failing the hardware used to
implement the RAID-5 protection.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 243 of 287

If the controller implementing the RAID-5 is contained within the disk enclosure (or similar
externally attached device), then the Sponsor must demonstrate they can still access the data stored
within the enclosure.
If the controller implementing the RAID-5 is separate from the enclosure containing the disks, andthe controller is not being used as a Durable Medium (e.g. mirrored write caches), then it issufficient to fail the communications between the controller and the enclosure.
Redundancy Level Three (Full Redundancy): Includes Redundancy Level Two and guarantees
access to the data on Durable Media when a single failure occurs within the Durable Media
system, including communications between Tier B and the Durable Media system.
Comment 1: The Durable Media system includes all components necessary to meet the durability

requirements defined above. This does not include the Tier B system or the system bus, but does
include the adapter on the system bus and any and all components “downstream” from theadapter.
The intent of this clause is to test the ability of the Tier B system to withstandcomponent failures and continue processing of the Transactions.
Comment 2:

The components being tested by this clause are those that are considered to be Field
Replaceable Units (FRUs). It is not the intent of the clause to require Sponsors to test the durability of a
backplane inside a Durable Media enclosure or similar non-replaceable components. However, testing
the failover properties of storage controllers, including mirrored caches on a controller, and thecorresponding software, is within the intent of this clause.
Comment:

7.6.3.5

Test Procedure for Data Accessibility

1.

Determine the current number of completed trades in the database by running:
select count(*) as count1 from SETTLEMENT

2.

Start submitting Transactions and ramp up to the Data Accessibility Throughput Requirements(as defined in Clause 7.6.2) and satisfy those requirements for at least 5 minutes.
Comment: Once the Data Accessibility Throughput Requirements are met

no Driver configuration changes are permitted until the conclusion of step 5

no SUT configuration changes are permitted except those needed to satisfy steps 3 and 4

3.

Induce the failure described for the redundancy level being demonstrated.

4.

Begin the necessary recovery process.

5.

Continue running the Driver for 20 minutes.

6.

Terminate the run gracefully from the Driver.

7.

Retrieve the new number of completed trades in the database by running:
select count(*) as count2 from SETTLEMENT

7.6.3.6

8.

Compare the number of executed Trade-Result Transactions on the Driver to(count2 – count1). Verify that (count2 - count1) is equal to the number of successful Trade-Result
Transaction records in the Driver log file.

9.

Allow recovery process to complete as needed.

Requirement for Combinations of Durable Media Technologies

At least one of each combination of durable media technology, bus type, and redundancy level, (e.g.
SSD/RAID-10, SATA/RAID-5, FC/RAID-5) must be tested independently as specified in clause 7.6.3.5.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 244 of 287

7.6.4

Required Reporting for Data Accessibility

7.6.4.1

Redundancy Level

The Test Sponsor must report the Redundancy Level and describe the test(s) used to demonstratecompliance in the Report. A list of all combinations of Durable Media technologies tested in Clause
7.6.3.5 must be reported in the Report.
7.6.4.2

Data Accessibility Time Graph

A graph of the Trade-Results per second averaged over one-minute versus elapsed time must bereported in the Report for the run portions of the Data Accessibility tests, prepared in accordance withthe following conventions:

The x-axis represents the elapsed time for the runs described in Clause 7.6.3.5, steps 2 through 6

The y-axis represents the throughput (computed as the total number of Trade-Result Transactions
that complete within each one-minute interval divided by 60)

A plot interval size of 1 minute must be usedA horizontal line at 95% of the Reported Throughput must also be plotted across the graphComment: The intent is to show how throughput is affected during recovery.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 245 of 287

CLAUSE 8 -- PRICING
Rules for pricing the Priced Configuration and associated software and maintenance are included TPC
Pricing Specification, located at www.tpc.org.
The following requirements are intended to supplement the TPC Pricing Specification:

8.1

Priced Configuration
The system to be priced is the aggregation of the SUT and any additional component that would be
required to achieve the reported performance level. Calculation of the priced system consists of:Price of the SUT as tested and as defined in Clause 4.2.5.

Price of any additional storage and associated infrastructure required by the On-Line Storage
Requirement in Clause 8.2.

Price of additional products that are required for the operation, administration or maintenanceof the priced system.

Price of additional products required for Application development.

Comment: Any component, for example a Network Interface Card (NIC), must be included in the priceof the SUT if it draws resources for its own operation from the SUT. This includes, but is not limited
to, power and cooling resources. In addition, if the component performs any function defined in the
TPC-E specification it must be priced regardless of where is draws its resources.

8.2

On-line Storage Requirement

8.2.1

A storage device is considered On-Line if it is capable of providing an access time to data, for random
read or update, of one second or less by the Operating System.
Comment: Examples of On-Line storage may include magnetic disks, optical disks, solid-state storage,
or any combination of these, provided that the above mentioned access criteria is met.

8.2.2

On-Line storage must be priced for sufficient space to store and maintain the data and User-Defined
Objects generated during a period of 60 Business Days at the Reported Throughput called the 60-Day
Period. The calculation of 60-Day Space is described in Clause 6.6.6.6.

8.2.3

The first Business Day of storage must satisfy the requirements of the Clause 6.6.7Continuous
Operations Requirement.

8.2.4

The device(s) for the remaining 59 Business Days of storage must be capable of being On-Line andcapable of meeting the Data Accessibility requirements (see Clause 7.6). All, some or none of the 59
Business Days of storage may be present in the Measured Configuration.


If the Measured Configuration contains more data storage than the 60-Day Space requires, allof the configured data storage must be priced. The amount of storage priced cannot be lessthan what was configured in the Measured Configuration.



If the Measured Configuration contains one or more devices identified by the Test Sponsor as
satisfying the 59 Business Days of storage, these devices must be On-Line. Any additional
storage device(s) priced must be of the same type(s).

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 246 of 287



If the Measured Configuration does not contain any devices that are identified by the Test
Sponsor as satisfying the 59 Business Days of storage, the storage device(s) priced must be of
the same type(s) used to satisfy the requirements of the Clause 6.6.7 Continuous Operations
Requirement.

Comment: Storage devices are considered to be of the same type if they are identical in all aspects of
their product description and technical specifications.
8.2.5

Archive Operation Requirement
TPC-E has no requirements for pricing additional archive storage.

8.2.6

Back-up Storage Requirements
TPC-E has no requirements for on-line back-up data capabilities in the Priced Configuration.

8.3

TPC-E Specific Pricing Requirements

8.3.1

Additional Operational Components

8.3.1.1

Additional products that might be included on a customer installed configuration, such as operator
consoles and magnetic tape drives, are also to be included in the priced system if explicitly required forthe operation, administration, or maintenance, of the priced system.

8.3.1.2

Copies of the software, on appropriate media, and a software load device, if required for initial load or
maintenance updates, must be included.

8.3.1.3

The price of an Uninterruptible Power Supply, specifically contributing to a Durability solution, must
be included (see Clause 7.6.3.2).

8.3.1.4

The price of all components, including cables, used to interconnect components of the SUT must be
included.

8.3.2

Additional Software

8.3.2.1

All software licenses must be priced for a number of users at least equal to one user for each tpsE ofNominal Throughput. Any usage pricing for this number of users must be based on the pricing policyof the company supplying the priced component.

8.3.2.2

The price must include the software licenses necessary to create, compile, link, and execute thisbenchmark Application as well as all run-time licenses required to execute on host system(s), clientsystem(s) and connected workstation(s) if used.

8.3.2.3

In the event the Application Program is developed on a system other than the SUT, the price of thatsystem and any compilers and other software used must also be included as part of the priced system.

8.4

Component Substitution

8.4.1

Substitution is defined as a deliberate act to replace components of the Priced Configuration by the
Test Sponsor as a result of failing the availability requirements of the TPC Pricing Specification orwhen the Part Number for a component changes.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 247 of 287

Comment: Corrections or "fixes" to components of the Priced Configuration are often required during

the life of products. These changes are not considered Substitutions so long as the Part Number of thepriced component does not change. Suppliers of hardware and software may update the components of
the Priced Configuration, but these updates must not impact the Reported Throughput. The following
are not considered Substitutions:

8.4.2

8.4.3



software patches to resolve a security vulnerabilitysilicon revision to correct errors



new supplier of functionally equivalent components (i.e. memory chips, disk drives, ...)

Some hardware components of the Priced Configuration may be substituted after the Test Sponsor has
demonstrated to the Auditor's satisfaction that the substituting components do not negatively impact
the Reported Throughput. All Substitutions must be reported in the Report and noted in the
Auditor's Attestation Letter. The following hardware components may be substituted:

Durable Medium

Durable Medium Enclosure

Network interface card

Router

Bridge

Repeater

Tier A (see Clause 4.2.3) hardware and software components may be substituted if the Test Sponsor
can demonstrate to the Auditor's satisfaction the components are separate from similar components ofTier B (see Clause 4.2.4) and do not negatively impact the Reported Throughput.
Comment: The intent of this clause is to allow Substitution of the hardware and software components ofTier A, if those components are not integral or shared with Tier B. Some examples are:1.

Tier A and Tier B are composed of different systems and Operating Systems. Tier A is a single
processor system and Tier B is a multi-processor system. There are no common or sharedcomponents between Tier A and Tier B. Any of the Tier A components may be substituted.

2.

Tier A and Tier B share the same physical cabinet, backplane or bus and power supply. However,
the tiers are demonstratively separated in all other aspects (processors, memory, Operating System,boot disk, etc.). Only the Tier A components that are separate may be substituted. Sharedcomponents between the tiers may not be substituted.

3.

Tier A is running within a guest operating system on Tier B (either through software partitioningor a virtual environment). Only the software for Tier A may be substituted for. Since the primary
hardware components are shared or virtualized they cannot be substituted.

The examples above are not representative of all possible combinations of the Tier A and Tier B
components. They are provided to cover the broad categories of separate systems, hardware
partitioning and software partitioning (virtualization).

8.5

Required Reporting

8.5.1

Two metrics will be reported with regard to pricing. The first is the total 3-year pricing as described in
the effective version of the TPC Pricing specification. The second is the total 3-year pricing divided by
the Reported Throughput (tpsE), as defined in Clause 6.7.1.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 248 of 287

8.5.2

The 3-year pricing metric must be fully reported in the basic monetary unit of the local currency unit
rounded up and the Price/Performance Metric must be reported to a minimum precision of threesignificant Digits rounded up. Neither metric may be interpolated or extrapolated. For example, if thetotal price is $ 5,734,417.89 USD and the Reported Throughput is 105 tpsE, then the 3-year pricing is $5,734,418 USD and the price/performance is $ 54,700 USD per tpsE (5,734,418/105).

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 249 of 287

CLAUSE 9 -- FULL DISCLOSURE REPORT
9.1

Full Disclosure Report Requirements
A Full Disclosure Report (FDR) is required. This section specifies the requirements for the FDR.
The FDR is a zip file of a directory structure containing the following:A Report in Adobe Acrobat PDF format,



An Executive Summary Statement in Adobe Acrobat PDF format,



An XML document (“ES.xml”) with approximately the same information as in the Executive
Summary Statement,

The Supporting Files consisting of various source files, scripts, and listing files. Requirements for
the FDR file directory structure are described below.

Comment: The purpose of the FDR is to document how a benchmark Result was implemented andexecuted in sufficient detail so that the Result can be reproduced given the appropriate hardware andsoftware products.
9.1.1

General Items

9.1.1.1

The order and titles of sections in the Report and Supporting Files must correspond with the order andtitles of sections from the TPC-E Standard Specification (i.e., this document). The intent is to make it aseasy as possible for readers to compare and contrast material in different Reports.

9.1.1.2

The FDR must follow all reporting rules specified in the effective version of the TPC Pricing
Specification, located at www.tpc.org. For clarity and readability the TPC Pricing Specification
requirements may be repeated in the TPC-E Specification.

9.1.1.3

The directory structure of the FDR has three folders:

ExecutiveSummaryStatement - contains the Executive Summary Statement and ES.xml



Report - contains the Report,SupportingFiles - contains the Supporting Files.

9.1.1.4

The reporting requirements of Clause 9 require descriptions, scripts and step by step GUI instructions
that are necessary to reproduce the benchmark Result. The Test Sponsor can only provide
descriptions, scripts and GUI instructions for the measured SUT as no knowledge is available at thetime of publication of future changes in hardware or software. To meet the Clause 9.1 reproducibility
requirement, the Test Sponsor must provide upon request any and all updated descriptions, scripts
and step by step GUI instructions required to reproduce the benchmark Result.

9.2

Executive Summary Statement
The TPC Executive Summary Statement must be included near the beginning of the Report. An
example of the Executive Summary Statement is presented in Appendix B. The latest version of therequired format is available from the TPC Administrator. When the optional TPC-Energy standard isused, the additional requirements and formatting of TPC-Energy related items in the executive
summary must be reported and used. In addition, the requirements of the TPC-Energy Specification,
located at www.tpc.org, must be met.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 250 of 287

9.2.1First Page of the Executive Summary Statement

9.2.1.1

The first page of the Executive Summary Statement must include the following:

Sponsor’s name

Measured server’s name

TPC-E Specification version number under which the benchmark is published

TPC-Pricing Specification version number under which the benchmark is publishedReport date and/or Revision DateReported Throughput in tpsE (see Clause 6.7.1)

Price/Performance Metric (see TPC Pricing Specification)

Availability Date (see TPC Pricing Specification)Total System Cost (see TPC Pricing Specification)

Database server’s Operating System name and version



Database Manager name and version

Number of Database Server Processors/Cores/Threads that were enabled for the benchmark (seeTPC Policies located at www.tpc.org)

Memory in GB configured on the Database Server

A diagram (see Clause 9.3.1.2) describing the components of the Priced Configuration (see TPC
Pricing Specification)

Initial Database Size in GBRedundancy Level and Redundancy Level implementation details

Priced number of Durable Media (disks) for the database

9.2.2

Additional Pages of Executive Summary Statement

9.2.2.1

The Price Spreadsheet must be included in the Executive Summary Statement as specified by the TPC
Pricing Specification.
Price Spreadsheet Categories:
The major categories for division of the price spreadsheet are:

Server HardwareServer StorageServer SoftwareClient HardwareClient SoftwareInfrastructure (networking, UPS, consoles, other components that do not fit into the above
categories)

9.2.2.2

The name of the Auditor who certified the result must be included after the Price Spreadsheet.

9.2.2.3

The numerical quantities listed below must be included in the Executive Summary Statement after thePrice Spreadsheet:Reported Throughput in tpsE (see Clause 6.7.1)

Configured Customers (see Clause 2.6)

Measurement Interval in hh:mm:ss (hours, minutes, seconds) (see Clause 6.6.1.5),

Ramp-up time in hh:mm:ss (see Clause 6.6.1.2),
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 251 of 287



Business Recovery Time in hh:mm:ss (see Clause Error! Reference source not found.),

The number of Transactions in the Transaction Mix completed within the Measurement Interval,(report the total, and the number per Transaction type) (see Clause 6.3.1)

The number of each Transaction type (including Data-Maintenance) completed within the
Measurement IntervalPercentage of Transaction Mix for each Transaction type completed within the Measurement
Interval (see Clause 6.3.1).

Ninetieth percentile, minimum, maximum and average Response Times must be reported for all
Transactions of the Transaction Mix completed within the Measurement Interval (see Clause
6.5.1). All reported Response Times must be rounded up to two decimal places.

Maximum, minimum and average Response Times must be reported for Data-Maintenance.

Comment: Appendix B contains an example of an Executive Summary Statement. The intent is for data

to be conveniently and easily accessible in a familiar arrangement and style. It is not required toprecisely mimic the layout shown in Appendix B.
9.2.3

ES.xml Requirements

9.2.3.1

The schema of the ES.xml document is defined by the XML schema document tpce-es.xsd (available
from www.tpc.org). The ES.xml file must conform to the tpce-es.xsd (established by XML schema
validation).
Comment: The Sponsor is responsible for verifying that the ES.xml file they provide in the FDR
conforms to the TPC-E XML schema. A validation tool will be provided on the TPC web site to facilitate
this verification.

9.2.3.2

Appendix C describes the structure of the XML schema, defines the individual attributes and elements,and explains how to use the schema.

9.3

Report Disclosure Requirements

9.3.1

Report Introduction

9.3.1.1

A statement identifying the benchmark Sponsor(s) and other participating companies must be reported
in the Report.

9.3.1.2

Diagrams of both Measured and Priced Configurations must be reported in the Report, accompanied
by a description of the differences. This includes, but is not limited to:

Number and type of processors, number of cores and number of threads.

Size of allocated memory, and any specific mapping/partitioning of memory unique to the test.



Number and type of disk units (and controllers, if applicable).



Number of channels or bus connections to disk units, including their protocol type.



Number of LAN (e.g. Ethernet) connections, including routers, workstations, etc., that were
physically used in the test or incorporated into the pricing structure.

Type and the run-time execution location of software components (e.g. DBMS, client, processes,
transaction monitors, software drivers, etc.).

Comment: Detailed diagrams for system configurations and architectures can widely vary, and it is

impossible to provide exact guidelines suitable for all implementations. The intent here is to describe
the system components and connections in sufficient detail to allow independent reconstruction of themeasurement environment.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 252 of 287

9.3.1.3

The following sample diagram illustrates a server benchmark (Measured) Configuration using a 32processor server. The server uses 3 SCSI Controllers each attached to four 72GB 15Krpm drives. Gigabit
Ethernet is used to link the Driver machine to the middle-tier machines, and the middle-tier machines
to the server. Note that this diagram does not depict or imply any optimal configuration for the TPC-E
benchmark measurement.
Tier A, 3 x PetitSystem (each with)
Model yyy CPU @ 2 GHz
2 Processors, 4 Cores, 8 Threads
512 MB Memory
2 Gigabit Ethernet Controllers
1 x 72GB @15,000 rpm

Tier B, 1 x GrosSystem
Model xxx CPU @ 5 GHz
32 Proc., 64 Cores, 128 Threads
1,024 GB Memory
3 SCSI Controllers
1 Gigabit Ethernet Controller

DataApp. Server

Gigabit

Gigabit

Data

App. Server
Data

Driver3 x 4 x 72GB
@ 15,000 rpm
Database ServerApp. Server

System Under Test
Figure 9.a - Example of Measured Benchmark Configuration
9.3.1.4

A description of the steps taken to configure all of the hardware must be reported in the Report. Any
and all configuration scripts or step by step GUI instructions are reported in the Supporting Files (seeClause 9.4.1). The description, scripts and GUI instructions must be sufficient such that a reader
knowledgeable of computer systems and the TPC-E specification could recreate the hardware
environment. This includes, but is not limited to:A description of any firmware updates or patches to the hardware.



A description of any GUI configuration used to configure the system hardware.



A description of exactly how the hardware is combined to create the complete system. For example,
if the SUT description lists a base chassis with 1 processor, a processor update package of 3
processors, a NIC controller and 3 disk controllers, a description of where and how the processors,
NIC and disk controllers are placed within the base chassis must be reported in the Report.



A description of how the hardware components are connected. The description can assume thereader is knowledgeable of computer systems and the TPC-E specification. For example, only adescription that Controller 1 in slot A is connected to Disk Tower 5 is required. The reader isassumed to be knowledgeable enough to determine what type of cable is required based upon thecomponent descriptions and how to plug the cable into the components.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 253 of 287

9.3.1.5

9.3.2

A description of the steps taken to configure all software must be reported in the Report. Any and all
configuration scripts or step by step GUI instructions are reported in the Supporting Files (see Clause
9.4.1.2). The description, scripts and GUI instructions must be sufficient such that a reader
knowledgeable of computer systems and the TPC-E specification could recreate the softwareenvironment. This includes, but is not limited to:A description of any updates or patches to the software.



A description of any changes to the software.



A description of any GUI configurations used to configure the software.

Clause 2 Database Design, Scaling & Population Related Items
A description of the steps taken to create the database for the Reported Throughput must be reported
in the Report. Any and all scripts or step by step GUI instructions are reported in the Supporting Files(see Clause 9.4.2). The description, scripts and GUI instructions must be sufficient such that a reader
knowledgeable of database software environments and the TPC-E specification could recreate thedatabase. This includes, but is not limited to the requirements specified in the following 9.3.2 clauses.

9.3.2.1

The physical organization of tables and User-Defined Objects, within the database, must be reported
in the Report.
Comment: The concept of physical organization includes, but is not limited to: record clustering (i.e.,rows from different logical tables are co-located on the same physical data page), index clustering (i.e.,rows and leaf nodes of an index to these rows are co-located on the same physical data page), andpartial fill-factors (i.e., physical data pages are left partially empty even though additional rows areavailable to fill them).
9.3.2.2

While few restrictions are placed upon horizontal or vertical partitioning of tables and rows in the TPCE benchmark (see Clause 2.3.3), any such partitioning must be reported in the Report. Using the
CUSTOMER table as an example, such partitioning could be denoted as:
C_part_1

C_ID
C_TAX_ID
C_ST_ID
C_L_NAME
C_F_NAME
C_M_NAME
C_GNDR
C_TIER
C_DOB
C_AD_ID------------ Vertical partition ------------------C_part_2

C_CTRY_1
C_AREA_1
C_LOCAL_1
C_EXT_1
C_CTRY_2
C_AREA_2
C_LOCAL_2

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 254 of 287

C_EXT_2
C_CTRY_3
C_AREA_3
C_LOCAL_3
C_EXT_3
C_EMAIL_1
C_EMAIL_2
Once the partitioned database elements have been so identified, they can be referred to by, for example,
their T_part_N notation when describing the physical allocation of database files (see Clause 9.3.2.6),
where T indicates the table name and N indicates the partition segment number.
9.3.2.3

Replication of tables, if used, must be reported in the Report (see Clause 2.3.4).

9.3.2.4

Additional and/or duplicated columns in any table must be reported in the Report along with astatement on the impact on performance (see Clause 2.3.5).

9.3.2.5

The cardinality (e.g. the number of rows) of each table, as it existed after database load (see Clause 2.6),
must be reported in the Report.

9.3.2.6

The distribution of tables, partitions and logs across all media must be explicitly depicted for the
Measured and Priced Configurations.
Comment: The intent is to provide sufficient detail to allow independent reconstruction of the test

database.
Disk #

Controller #Slot #

DrivesEnclosure model
RAID level

1

1

3

28 X 36.4GB EEENNN
Enclosure RAID 10

2

2

4

3

2

4
5

9.3.2.7

9.3.2.8

Partition/file system

Size

Use

E: (RAW)

200.00GB

DB LogF: (NTFS)

10.00GBMDF File

14 X 36.4GB EEENNN
Enclosure RAID 10

C:\mp\dimension (RAW)

0.10GB

Dimension

C:\mp\market (RAW)50.50GB

Market4

14 X 74.8GB EEENNN
Enclosure RAID 10

C:\mp\customer (RAW)70.00GB

Customer

G: (NTFS)

10.00GB

Backup 1

3

5

28 X 74.8GB EEENNN
Enclosure RAID 10

C:\mp\broker1 (RAW)44.25GB

BrokerH: (NTFS)

10.00GB

Backup 2

4

1

28 X 74.8GB EEENNN
Enclosure RAID 10

C:\mp\broker2 (RAW)44.25GB

BrokerI: (NTFS)

10.00GB

Backup 3

A statement must be provided in the Report that describes:


The Database Interface (e.g., embedded, call level) and access language (e.g., SQL, COBOL
read/write) used to implement the TPC-E Transactions. If more than one interface / accesslanguage is used to implement TPC-E, each interface / access language must be described and a listof which interface /access language is used with which Transaction type must be reported.

The data model implemented by the DBMS (e.g., relational, network, hierarchical).

The methodology used to load the database must be reported in the Report.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 255 of 287

9.3.3

Clause 3 Transaction Related Items

9.3.3.1

A statement that vendor-supplied code is functionally equivalent to Pseudo-code in the specification(see Clause 3.2.1.6) must be reported in the Report.

9.3.3.2

A statement that the database footprint requirements (as described in Clause 3.3) were met must bereported in the Report.

9.3.4

Clause 4 SUT, Driver, and Network Related Items

9.3.4.1

The Network configurations of both the Measured and Priced Configurations must be described andreported in the Report. This includes the mandatory Network between the Driver and Tier A (seeClause 4.2.2) and any optional Database Server interface networks (see Clause 4.1.3.12).

9.3.5

Clause 5 EGen Related Items

9.3.5.1

The version of EGen used in the benchmark must be reported in the Report (see Clause 5.3.1).

9.3.5.2

A statement that all required TPC-provided EGen code was used in the benchmark must be reported in
the Report.

9.3.5.3

If the Test Sponsor modified EGen, a statement EGen has been modified must be reported in theReport. All formal waivers from the TPC documenting the allowed changes to EGen must also bereported in the Report (see Clause 5.3.7.1). If any of the changes to EGen do not have a formal waiverthat must also be reported in the Report.

9.3.5.4

If the Test Sponsor extended EGenLoader (as described in Appendix A.6), the use of the extended
EGenLoader and the audit of the extension code by an Auditor must be reported in the Report (seeClause 5.7.4).

9.3.5.5

The make/project files used to compile/link EGenLoader and EGenValidate must be reported in the
Supporting Files. The compiler/linker options and flags used to compile/link EGen Objects for the
SUT must be reported in the Supporting Files.

9.3.6

Clause 6 Performance Metrics and Response Time Related Items

9.3.6.1

The number of EGenDriverMEE and EGenDriverCE instances used in the benchmark must bereported in the Report (see Clause 6.2.5).

9.3.6.2

The Reported Throughput must be reported in the Report (see Clause 6.7.1.2).

9.3.6.3

A Test Run Graph of throughput versus elapsed wall clock time must be reported in the Report for the
Trade-Result Transaction (see Clause 6.7.2).

9.3.6.4

The method used to determine that the SUT had reached a Steady State prior to commencing the
Measurement Interval must be reported in the Report.

9.3.6.5

A description of how the work normally performed during a Test Run, actually occurred during the
Measurement Interval must be reported in the Report (for example checkpointing, writing Undo/RedoLog records, etc.).

9.3.6.6

The recorded averages over the Measurement Interval for each of the Transaction input parametersspecified by clause 6.4.1 must be reported in the Report.
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 256 of 287

9.3.7

Clause 7 Transaction and System Properties Related Items

9.3.7.1

The results of the ACID tests must be reported in the Report along with a description of how the ACID
requirements were met, and how the ACID tests were run.

9.3.7.2

The Test Sponsor must report in the Report the Redundancy Level (see Clause 7.6.3.4) and describe theData Accessibility test(s) used to demonstrate compliance. A list of all combinations of Durable
Media technologies tested in Clause 7.6.3.5 must be reported in the Report.

9.3.7.3

A Data Accessibility Graph for each run demonstrating a Redundancy Level must be reported in theReport (see Clause 7.6.4.2).

9.3.7.4

The Test Sponsor must describe in the Report the test(s) used to demonstrate Business Recovery.

9.3.7.5

The Business Recovery Time Graph (see Clause 7.5.8.2) must be reported in the Report for all
Business Recovery tests.

9.3.8

Clause 8 Pricing Related Items

9.3.8.1

Details of the 60-Day Space computations (see Clause 6.6.6.6) along with proof that the database isconfigured to sustain a Business Day of growth (see Clause 6.6.6.1) must be reported in the Report.

9.3.8.2

The Auditor’s Attestation Letter, which indicates compliance, must be included in the Report.

9.3.9

Supporting Files Index Table
An index for all files required by Clause 9.4 Supporting Files must be provided in the Report. The
Supporting Files index is presented in a tabular format where the columns specify the following:

The first column denotes the clause in the TPC Specification

The second column provides a short description of the file contents

The third column contains the path name for the file starting at the SupportingFiles directory.

If there are no Supporting Files provided then the description column must indicate that there is no
supporting file and the path name column must be left blank.
Comment: This may be the common case for Clause 9.4.5 where EGen modifications are required in the

Supporting Files.
9.3.9.1

The following table is an example of the Supporting Files Index Table that must be reported in theReport.
ClauseIntroduction

Clause 2

Clause 3

Clause 4

Description

Pathname

Database Tunable Parameters SupportingFiles/Introduction/DBtune.txt
OS Tunable Parameters

SupportingFiles/Introduction/OStune.txt

Table creation scripts

SupportingFiles/Clause2/createTables.sh

Index creation scripts

SupportingFiles/Clause2/createIndex.shLoad Transaction Frames

SupportingFiles/Clause2/createFrames.sh

Broker-Volume Frames

SupportingFiles/Clause3/BrokerVolume.txt

Trade-Order Frames

SupportingFiles/Clause3/TradeOrder.txt

Trade-Result Frames

SupportingFiles/Clause3/TradeResult.txt

There are no files required to be included for Clause 4.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 257 of 287

No EGen modifications
No EGenLoader extensions

Clause 5

Clause 6
Clause 7
Clause 8

9.4

EGenDriver Configuration

SupportingFiles/Clause5/DriverConfig.txt

EGenLoader Parameters

SupportingFiles/Clause5/LoaderParams.txt

CCE 1 EGenLogger Output

SupportingFiles/Clause5/CCE1.out

CCE 2 EGenLogger Output

SupportingFiles/Clause5/CCE2.out

CMEE EGenLogger Output

SupportingFiles/Clause5/CMEE.out

EGenValidate Output

SupportingFiles/Clause6/Validate.out

ACID Scripts

SupportingFiles/Clause7/runACID.sh

Output of ACID tests

SupportingFiles/Clause7/ACID.out

60-Day Space Calculations

SupportingFiles/Clause8/sixty.xls

Supporting FilesThe Supporting Files contain human readable and machine executable (i.e., able to be performed by
the appropriate program without modification) scripts that are required to recreate the benchmark
Result. If there is a choice of using a GUI or a script, then the machine executable script must be
provided in the Supporting Files. If no corresponding script is available for a GUI, then the Supporting
Files must contain a detailed step by step description of how to manipulate the GUI.
The directory structure under SupportingFiles must follow the clause numbering from the TPC-E
Standard Specification (i.e., this document). The directory name is specified by the 9.4 third level
Clauses immediately preceding the fourth level Supporting Files reporting requirements. If there ismore than one instance of one type of file, subfolders may be used for each instance. For example if
multiple Tier A machines were used in the benchmark, there may be a folder for each Tier A machine.
File names should be chosen to indicate to the casual reader what is contained within the file. For
example, if the requirement is to provide the scripts for all table definition statements and all otherstatements used to set-up the database, file names of 1, 2, 3, 4 or 5 are unacceptable. File names that
include the text “tables”, “index” or “frames” should be used to convey to the reader what is being
created by the script.

9.4.1

SupportingFiles/Introduction Directory

9.4.1.1

All scripts required to configure the hardware must be reported in the Supporting Files.

9.4.1.2

All scripts required to configure the software must be reported in the Supporting Files. This includes
any Tunable Parameters and options which have been changed from the defaults in commerciallyavailable products, including but not limited to:Database tuning options.



Recovery/commit options.

Consistency/locking options.



Operating System and application configuration parameters.

Compilation and linkage options and run-time optimizations used to create/install applications,OS, and/or databases.

Parameters, switches or flags that can be changed to modify the behavior of the product.

Comment: This requirement can be satisfied by providing a full list of all parameters and options.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 258 of 287

9.4.2

SupportingFiles/Clause2 Directory

9.4.2.1

Scripts and outputs must be provided for all table definition statements and all other statements used
to set-up and populate the database. All scripts must be human readable and machine executable (i.e.,able to be performed by the appropriate program without modification). All scripts and outputs are to
be reported in the Supporting Files.

9.4.3

SupportingFiles/Clause3 Directory

9.4.3.1

The Frame Implementation (as described in Clause 4.2) of each Transaction must be reported in the
Supporting Files. This includes, but is not limited to, the code implementing the twelve Transactions(see Clause 3.3) of this benchmark.

9.4.4

SupportingFiles/Clause4 Directory

9.4.4.1

No requirements

9.4.5

SupportingFiles/Clause5 Directory

9.4.5.1

If the Test Sponsor modified EGen, the changes must be reported in the Supporting Files.

9.4.5.2

If the Test Sponsor extended EGenLoader (as described in Appendix A.6), the extension code must bereported in the Supporting Files.

9.4.5.3

The EGenDriverCE, EGenDriverMEE and EGenDriverDM configuration must be reported in the
Supporting Files.

9.4.5.4

The EGenLoader parameters used must be reported in the Supporting Files.

9.4.5.5

The EGenLogger output for each CCE object, CMEE object and CDM object must be reported in the
Supporting Files (see Clause 5.8.1).

9.4.6

SupportingFiles/Clause6 Directory

9.4.6.1

The output from EGenValidate must be reported in the Supporting Files (see Clause 6.7.4).

9.4.7

SupportingFiles/Clause7 Directory

9.4.7.1

The ACID scripts and the output of the ACID tests must be reported in the Supporting Files.

9.4.8

SupportingFiles/Clause8 Directory

9.4.8.1

A spreadsheet detailing the 60-Day Space calculations must be reported in the Supporting Files.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 259 of 287

CLAUSE 10 -- INDEPENDENT AUDIT
10.1

General Rules

10.1.1

Prior to its publication, a TPC-E Result must be reviewed by a TPC-Certified, independent Auditor.
Comment 1: The term TPC-Certified is used to indicate that the TPC has reviewed the qualification of

the Auditor and has certified his/her ability to verify that benchmark Results are in compliance withthis specification. (Additional details regarding the Auditor certification process and the audit process
can be found in the TPC Policy document.)
Comment 2: The Auditor must be independent from the Sponsor in that the outcome of the benchmark

carries no financial benefit to the Auditor, other than fees earned as a compensation for performing theaudit. More specifically:

The Auditor is not allowed to have supplied any performance consulting for the benchmark
under audit.



The Auditor is not allowed to be financially related to the Sponsor or to any one of the suppliersof a measured/priced component (e.g., the Auditor cannot be an employee of an entity owned
wholly or in part by the Sponsor or by the supplier of a benchmarked component, and the
Auditor cannot own a significant share of stocks from the Sponsor or from the supplier of any
benchmarked component, etc.)

10.1.2

All audit requirements specified in the version of the TPC Pricing Specification, located at www.tpc.org
must be followed. For clarity and readability the TPC Pricing Specification requirements may berepeated in the TPC-E Specification.

10.1.3

When the optional TPC-Energy standard is used, the additional audit requirements must be followed.
In addition, the requirements of the TPC-Energy Specification, located at www.tpc.org, must be met.

10.1.4

A generic audit checklist is provided as part of this specification. The Auditor may choose to provide
the Sponsor with additional details on the TPC-E audit process.

10.1.5

The generic audit checklist specifies the TPC-E requirements that should be checked to ensure a TPC-E
Result is compliant with the TPC-E Specification. The TPC-E requirements may also be required to bereported in the FDR. Not only should the TPC-E requirement be checked for accuracy but the Auditor
must ensure that the FDR accurately reflects the audited Result. For example, if the audit checklist
indicates to “verify that a Business Recovery Time Graph is generated as specified”, the graph must be
verified to be accurate and verified to be the same graph that is reported in the FDR as specified byClause 9.3.7.5.

10.1.6The Auditor’s opinion regarding the compliance of a Result must be consigned in an Attestation Letter
delivered directly to the Sponsor. To document that a Result has been audited, the Attestation Letter
must be included in the Report and made readily available to the public. Upon request, and after
approval from the Sponsor, a detailed audit report may be produced by the Auditor.

10.1.7The scope of the audit is limited to the functions defined in this specification. The ability to perform
arbitrary functions against the SUT (e.g., executing Transactions unrelated to those defined in Clause
3.3, generating input data unrelated to those produced by the CE and the MEE, creating data structures
unrelated to those necessary to implement Clause 2, etc.) is outside of the scope of the audit.

10.1.8A Sponsor can demonstrate compliance of a new Result produced without running any performance
test by referring to the Attestation Letter of another Result, if the following conditions are all met:
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 260 of 287



The referenced Result has already been published by the same or by another Sponsor.

The new Result must have the same hardware and software architecture and configuration as thereferenced Result. The only exceptions allowed are for elements not involved in the processing
logic of the SUT (e.g., number of peripheral slots, power supply, cabinetry, fans, etc.)



The Sponsor of the already published Result gives written approval for its use as referenced by theSponsor of the new Result.



The Auditor verifies that there are no significant functional differences between the priced
components used for both Results (i.e., differences are limited to labeling, packaging and pricing.)



The Auditor reviews the FDR of the new Result for compliance. The Auditor delivers a new
Attestation Letter to be included in the Report of the new Result.

Comment 1: The intent of this clause is to allow publication of benchmarks for systems with different

packaging and model numbers that are considered to be identical using the same benchmark run. For
example, a rack mountable system and a freestanding system with identical electronics can use thesame Test Run for publication, with, appropriate changes in pricing.
Comment 2: Although it should be apparent to a careful reader that the FDR for the two Results are

based on the same set of performance tests, the FDR for the new Result is not required to explicitly
state that it is based on the performance tests of another published Result.
Comment 3: When more than one Result is published based on the same set of performance tests, only

one of the Results from this group can occupy a numbered slot in each of the benchmark Result “TopTen” lists published by the TPC. The Sponsors of this group of Results must all agree on which Result
from the group will occupy the single slot. In case of disagreement among the Sponsors, the decision
will be made by the Sponsor of the earliest publication from the group.

10.2

Auditing the Database
The Auditor must verify that the implementation of the measured database meets the TPC-E
Specification requirements. The Auditor may require the review of any and all source code andassociated scripts or programs used to create and populate the database. The Auditor can require
additional database verification not specified in the TPC-E Specification to ensure the validity of thedatabase.

10.2.1

Schema Related Items

10.2.1.1

Verify that the data types used to implement the columns of the TPC-E required tables meet therequirements from Clause 2.2.1.

10.2.1.2

Verify that the data Meta-types used to implement the columns of the TPC-E required tables meet therequirements of Clause 2.2.2.

10.2.1.3

Verify that the 9 tables in the Customer set have all of the required properties (see Clause 2.2.4).

10.2.1.4

Verify that the 9 tables in the Broker set have all of the required properties (see Clause 2.2.5).

10.2.1.5

Verify that the 11 tables in the Market set have all of the required properties (see Clause 2.2.6).

10.2.1.6

Verify that the 4 tables in the Dimension set have all of the required properties (see Clause 2.2.7).

10.2.1.7

Verify that all Primary Keys, all Foreign Keys, and all check constraints specified are maintained by the
database (see Clause 2.2.3).
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 261 of 287

10.2.1.8

Verify that all copies of any replicated table, if used, meet all requirements for atomicity, consistency,
and isolation. Verify that at least one copy of any replicated TPC-E table meets Durability
requirements (see Clause 2.3.4).

10.2.1.9

Verify that adding or duplicating any columns from one TPC-E table to another does not result in a
performance improvement (see Clause 2.3.5).

10.2.1.10 Verify that all table columns are logically discrete (see Clause 2.3.6).
10.2.1.11 Verify that all table columns are accessible by the data manager as a single column (see Clause 2.3.7).
10.2.1.12 Verify that Primary Keys are not a direct representation of the physical disk addresses of the row (seeClause 2.3.8).
10.2.1.13 Verify that BLOB columns are implemented with the required properties (see Clause 2.3.10).
10.2.1.14 Verify that the implementation of the database satisfies the integrity rules (see Clause 2.4).
Comment: A check for the condition in clause 2.4.2 is not required, but the requirement still exists.

10.2.1.15 Verify that the implementation of the database satisfies the data access transparency requirements (seeClause 2.5).
10.2.2

Population Related Items

10.2.2.1

Verify that the version of EGenLoader used is compliant with the current version of the TPC-E
specification (see Clause 5.7.1).

10.2.2.2

Verify that none of the EGenLogger output contains “NO”. A “NO” indicates that the associatedEGenDriver or EGenLoader configuration parameter is not compliant with the current TPC-E
Specification (see Clause 5.2.9).

10.2.2.3

Verify that the database is populated using data generated by EGenLoader (see Clause 2.6.1.1).

10.2.2.4

Verify that the database is populated with an integral number of Load Units (see Clause 2.6.1.2).

10.2.2.5

Verify that the initial database population consists of a number of Business Days equal to ITD (seeClause 2.6.1.5).

10.2.2.6

Verify that the cardinality of the TPC-E required tables in the initially populated database meets therequirements of Clause 2.6.1.

10.2.2.7

Verify that each non-Growing Table can grow by a number of rows equal to at least 5% of the tablecardinality (see Clause 2.3.9).

10.3

Auditing the Transactions
The Auditor must verify that the implementation of the Transactions meets the TPC-E Specification
requirements. The Auditor may require the review of any and all source code and associated scripts orprograms for the Transactions. The Auditor can require additional Transaction verification not
specified in the TPC-E Specification to ensure the validity of the Transactions.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 262 of 287

10.3.1

Verify that the implementation of each Transaction specified in Clause 3.3 is compliant with its
respective input parameters, output parameters, Database Footprint and Frame Implementation
requirements. More specifically:

Verify that the Broker-Volume Transaction is compliant with the requirements defined in Clause
3.3.1.



Verify that the Customer-Position Transaction is compliant with the requirements defined in
Clause 3.3.2.

Verify that the Market-Feed Transaction is compliant with the requirements defined in Clause
3.3.3.



Verify that the Market-Watch Transaction is compliant with the requirements defined in Clause
3.3.4.



Verify that the Security-Detail Transaction is compliant with the requirements defined in Clause
3.3.5.



Verify that the Trade-Lookup Transaction is compliant with the requirements defined in Clause
3.3.6.



Verify that the Trade-Order Transaction is compliant with the requirements defined in Clause
3.3.7.



Verify that the Trade-Result Transaction is compliant with the requirements defined in Clause
3.3.8.



Verify that the Trade-Status Transaction is compliant with the requirements defined in Clause
3.3.9.



Verify that the Trade-Update Transaction is compliant with the requirements defined in Clause
3.3.10.



Verify that the Data-Maintenance Transaction is compliant with the requirements defined in
Clause 3.3.11.



Verify that the Trade-Cleanup Transaction is compliant with the requirements defined in Clause
3.3.12.

10.3.2

Verify that all Frames are implemented without circumventing any specified database references tostatic or infrequently changing data elements (see Clause 3.2.1.1).

10.3.3

Verify that Frames do not exchange data outside of the specified input and output parameters used tocommunicate with the EGenTxnHarness (see Clause 3.2.1.3).

10.3.4

Verify that implementation of each Frame is functionally equivalent to the Pseudo-code provided forthat Frame in Clause 3.3.

10.3.5

Verify that the Frame Implementation correctly sets null indicator variables in EGenTxnHarness
structures.

10.4

Auditing the SUT, Driver and Networks
The Auditor must verify that the implementation of the test environment meets the TPC-E Specification
requirements. The Auditor may require the review of any and all source code implementing thevarious components involved and associated scripts or programs. The Auditor can require additionalverification not specified in the TPC-E Specification to ensure the validity of the test environment.

10.4.1

Verify that the format of the data provided to the EGenDriver Connector and the EGenTxnHarness
Connector is not modified, except as permitted (see Clause 4.1.3.14).
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 263 of 287

10.4.2

Verify the Sponsor written code meets the requirement of Clause 4.4.1.1.

10.4.3

Verify that the “no-peeking-in-the-packet” rule is followed (see Clause 4.4.1.3).

10.4.4

Verify that the Driver meets the requirements of Clause 4.4.1.4.

10.4.5

Verify that the SUT meets the requirements of Clause 4.4.1.5

10.4.6

Verify that any routing within a Frame Implementation meets the requirements of Clause 4.4.1.6.

10.4.7

Verify the presence and use of a Network to communicate between the Driver and Tier A (see Clause
4.2.2).

10.4.8

Verify that the restrictions on operator interventions are met (see Clause 4.4.3).

10.5

Auditing EGen

10.5.1

Verify that the version of EGen used is compliant with the version of the TPC-E specification used for
publication (see Clause 5.3).


Verify that the EGenSourceFiles used have not been modified (see Clause 5.6).



If the Test Sponsor modified EGen in response to a formal waiver issued by the TPC, verify
that the changes fall under the scope of the waiver (see Clause 5.3.7).



If the Test Sponsor modified EGen outside of an existing TPC waiver, review the changes toverify that it was done for the exclusive purpose of correcting a newly discovered error in
EGen (see Clause 5.3.6).

10.5.2

Verify that the requirements in Clause 5.3.5 are satisfied.

10.5.3

Verify that modifications or extensions made by the Sponsor to EGenLoader do not compromise thevalues for the data generated by EGenLoader (see Clause 5.7.4).

10.5.4

Verify that the CE is implemented using the EGenDriverCE (see Clause 5.8.5).

10.5.5

If an Asynchronous CE Driver Architecture was used, verify that the CE Driver meets the requirementsof Clause 6.2.3.1.

10.5.6

Verify that the MEE is implemented using EGenDriverMEE (see Clause 5.8.6).

10.5.7

Verify that the Data-Maintenance Transaction is implemented using EGenDriverDM (see Clause
5.8.7).

10.5.8

Verify that the implementation uses EGenTxnHarness (see clause 5.9.1).

10.5.9Verify that the contents of the EGenInputFiles used are for the correct version of EGen used, that they
have not been modified, and that all copies of the EGenInputFiles are identical and used in all
EGenLoader and Driver instances (see Clause 5.8.4).

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 264 of 287

10.6

Auditing the Execution Rules and Metrics
The Auditor must verify that all TPC-E execution rules have been followed by the Test Sponsor. The
Auditor may require the review of any and all output of the benchmark environment. The Auditor canrequire additional verification not specified in the TPC-E Specification to ensure the validity of the
Benchmark Execution Rules and the resulting Reported Throughput.

10.6.1Pre-run Configuration Items

10.6.1.1

Verify that the contents of the database meet the requirements of Clause 6.6.2.1 and Clause 6.6.2.3.

10.6.1.2

Verify that the Trade-Cleanup Transaction was executed prior to the start of the Test Run or that the
database was in its initially populated state (e.g., verify that the final TRADE count minus the numberof Trade-Orders completed by the Driver during the Test Run is equal to the initial TRADE count) (seeClause 6.6.2.2).

10.6.1.3

Verify that no executions of the Trade-Cleanup Transaction occur during the Test Run (see Clause
6.6.1.1).

10.6.1.4

Verify that the system clocks are synchronized as required by Clause 4.4.4.

10.6.2

Runtime Configuration Items

10.6.2.1

Verify that, for specific global inputs, each instance of the CE, DM and the MEE is using the samevalues as those used by the EGenLoader instances during the initial database population (see Clause
5.8.4). This requirement applies to the following global inputs:The contents of each flat_in file.



The value for Scale Factor (SF).

The number of Initial Trade Days.



The number of Configured Customers.

10.6.2.2

Verify that none of the EGenLogger output contains “NO”. A “NO” indicates that the associatedEGenDriver or EGenLoader configuration parameter is not compliant with the current TPC-E
Specification (see Clause 5.2.9).

10.6.2.3

If an Asynchronous CE Driver Architecture was used, verify that the CE Driver meets the requirementsof Clause 6.2.3.1.

10.6.3

Runtime Data Generation Items

10.6.3.1

Verify that the reported Transaction Mix over the Measurement Interval only counts Valid
Transactions (see Clause 6.3).

10.6.3.2

Verify that the reported Transaction Mix over the Measurement Interval excludes the DataMaintenance Transactions (see Clause 6.3.1).

10.6.3.3

Verify that the specified mix of Transactions over the Measurement Interval meets the requirements(see Clause 6.3.1).

10.6.3.4

Verify that the reported Transaction Mix over the Measurement Interval is computed and reportedwith the required precision and rounding (see Clause 6.3.2).

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 265 of 287

10.6.3.5

Verify that the CE Driver generated input data with a random variability that stays within the specified
ranges (see Clause 6.4.1).

10.6.3.6

Verify that the number of Load Units configured for the database is equal to the number of Load Units
actually accessed during the Test Run (see Clauses 2.6.1.6 and 6.6.8.5).

10.6.4

Response Time Items

10.6.4.1

Verify that the Transaction Response Times meet the requirements of Clause 6.5.1.2.

10.6.4.2

Verify for each type of Transaction that its average Response Times does not exceed its 90th percentile
Response Time (see Clause 6.5.1.4).

10.6.4.3

Verify that the Dispatch Time meets the requirements of Clause 6.5.2.

10.6.5

C_ID Partitioning Items

10.6.5.1

If C_ID partitioning was used, verify that the CE Driver meets the requirements of Clause 6.4.2.1.

10.6.5.2

If C_ID partitioning was used, verify that the Measurement Interval meets the requirements in Clause
6.4.2.2.

10.6.6

Throughput Items

10.6.6.1

Verify the Measured Throughput is between 80% and 102% of the Nominal Throughput (see Clause
6.7.1.2).

10.6.6.2

Verify that the Reported Throughput is not greater than the Nominal Throughput (see Clause 6.7.1.2).

10.6.7

Data-Maintenance Items

10.6.7.1

Verify that one, and only one, Data-Maintenance Transaction generator is used during the Test Run(see Clause 5.8.7.2).

10.6.7.2

Verify that during the Measurement Interval the Data-Maintenance Transaction is invoked every 60
seconds and completes within no more than 55 seconds (see Clause 6.3.3).

10.6.7.3

Verify that the Data-Maintenance Transaction modified the rows specified in Clause 3.3.11.

10.6.8

Steady State Items

10.6.8.1

Verify that the Steady State meets the requirements of Sustainable performance as specified by Clause
6.6.3.

10.6.8.2

Verify that all events performed at regular intervals during Steady State are present before and during
the Measurement Interval as required (see Clause 6.6.4.1) and that the duration of Steady State meets
all the requirements listed in Clause 6.6.4.2.

10.6.8.3

Verify that the Measurement Interval meets all the requirements of Clause 6.6.5.

10.6.9EGenValidate Items

10.6.9.1

Verify that output from EGenValidate indicates “Passed!” (see Clause 6.7.4).
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 266 of 287

10.6.10

Space Calculation Items

10.6.10.1 Verify that the Data Growth is computed as specified and that sufficient space to accommodate it isavailable on-line (see Clause 6.6.6).

10.7

Auditing the ACID Tests
The Auditor must verify that the implementation of the ACID tests sufficiently demonstrates
compliance with the TPC-E ACID requirements. The Auditor may require the review the source code
implementing these tests and any associated scripts or programs. The Auditor can require additionalverification not specified in the TPC-E Specification to ensure the validity of the ACID tests.

10.7.1

Verify that all copies of any replicated table, if used, meet all requirements for atomicity, consistency,
and isolation. Verify that at least one copy of any replicated TPC-E table meets Durability
requirements (see Clause 2.3.4).

10.7.2

Atomicity Items

10.7.2.1

Verify that the atomicity test is implemented as specified in Clause 7.2.2.

10.7.2.2

Verify that the atomicity test correctly demonstrates the atomicity property (see Clause 7.2.1).

10.7.3

Consistency Items

10.7.3.1

Verify that the consistency tests are implemented as specified in Clause 7.3.3.

10.7.3.2

Verify that the consistency conditions are successfully demonstrated by the tests (see Clause 7.3.2)

10.7.4Isolation Items

10.7.4.1

Verify that the isolation tests are implemented as specified in Clause 7.4.2.

10.7.4.2

Verify that the isolation tests correctly demonstrate the isolation requirements (see Clause 7.4.1.3).

10.7.5

Data Accessibility Items

10.7.5.1

Verify that the Durability tests for Data Accessibility are implemented as specified (see Clause 7.6.3.5).

10.7.5.2

Verify that the Redundancy Level chosen by the Sponsor is successfully demonstrated by the Data
Accessibility test (see Clause 7.6.3.5).

10.7.5.3

Verify that the Redundancy Level chosen by the Sponsor is correctly reported in the Report (see Clause
7.6.3.4).

10.7.5.4

Verify that all components of Durable Media technologies tested in Clause 7.6.3.5 are correctly
reported in the Report.

10.7.5.5

Verify that a Data Accessibility Graph is generated as specified in Clause 7.6.4.2.

10.7.6

Business Recovery Items

10.7.6.1

Verify that the Durability tests for Business Recovery are implemented as specified (see Clause 7.5.7).

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 267 of 287

10.7.6.2

Verify that recovery from each required single failure scenario is successfully demonstrated by one ormore Business Recovery tests (see Clause 7.5.7).

10.7.6.3

Verify that the Business Recovery Time correctly measures the time between the start of Business
Recovery and the end of Business Recovery (see Clause 7.5.6.10).

10.7.6.4

Verify that a Business Recovery Graph is generated as specified in Clause 7.5.8.2.

10.8

Auditing the Pricing

10.8.1

Rules for auditing Pricing information are specified in the effective version of the TPC Pricing
Specification, located at www.tpc.org.

10.8.2

Verify that the greater of the 60-Day Space or the data storage configured during the measurement isincluded in the Priced Configuration (see Clause 8.2).

10.8.3

Verify that additional operational components or additional software that might be customary on acustomer installed configuration or might be necessary to build and run the Application are included(see Clause 8.3.1 and Clause 8.3.2).

10.8.4

Verify that all component Substitutions are compliant with the TPC Pricing Specification and with the
TPC-E specific restrictions (see Clause 8.4).

10.9

Auditing the FDR
For the Audit requirements specified in Clauses 10.5 through 10.8, the Auditor must ensure that if
required by Clause 9, the items, requirements or values are correctly reported in the FDR.
For those items, requirements or values that are reported in the FDR and not required to be audited,
the Auditor need only ensure that they are in the FDR and appear to be reasonable. For example, theAuditor can not be held responsible for accuracy of the Availability Date but can ensure that it isreported in the FDR and does not fall outside the 6 month availability window starting from thepublication date.

10.9.1

Verify that table partitioning, if used, meets the requirements from Clauses 2.3.3.

10.9.2

Verify that the reported Transaction Mix over the Measurement Interval is computed and reportedwith the required precision and rounding (see Clause 6.3.2).

10.9.3

Verify that the Reported Test Run Graph meets the requirements (see Clause 6.7.2).

10.9.4

Verify that the Executive Summary Statement is accurate and complies with the reporting
requirements as specified in Clause 9.2.

10.9.5For those items which are required by Clause 9.3 to be reported in the Report and are also required byClauses 10.5 through 10.8 to be verified by the Auditor, verify that the items are accurately reported in
the Report. For those items which are required to be reported by Clause 9.3 but are not required to beverified by the Auditor, ensure that the items are reported in the Report and appear to be reasonable.

10.9.6

Verify that the Supporting Files specified by Clause 9.4 exist and appear to be reasonable.

10.9.7

Verify that the following sections of the FDR are accurate:
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 268 of 287

10.9.8

Verify that the diagram illustrating the Measured Configuration is accurate (see Clause 9.3.1.2)



Verify that the diagram illustrating the Priced Configuration is accurate (see Clause 9.3.1.2)



Verify that the textual descriptions required by Clause 9.3.2 are accurate.

Verify that any EGen changes made by the Sponsor are reported in detail in the FDR (see Clause
9.3.5.3).

Verify that modifications or extensions made by the Sponsor to EGenLoader are documented in
sufficient detail in the Report and that the code for the modification or extension is reported in the
Supporting Files (see Clause 9.3.5.4).

A complete review of the Report by the Auditor, beyond the sections listed above, can be requested by
the Sponsor, but is not required.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 269 of 287

Appendix A. EGEN USER’S GUIDE
Overview

A.1

EGen is a TPC provided software package. It is designed to facilitate the implementation of TPC-E.
This appendix provides information on how a Test Sponsor is to use the features and functionality ofEGen. The definitions, descriptions, constraints and regulations governing the use of EGen are
captured in Clause 5 -- .
Comment: Some of the following sections assume the reader has a good understanding of object-oriented design and programming techniques using ANSI C++.

A.2

EGen Directory

A.2.1

EGen is distributed in a single directory hierarchy. The following diagram shows the overall EGen
directory hierarchy.
EGen

bin

flat_in

flat_out

inc

lib

obj

prj

win

Figure A.a - Hierarchy of EGen Directorybin – default target directory for executable binary files

flat_in - contains flat input files

flat_out - default target directory for flat file output



inc – contains header files



inc/win – Windows specific header files

*/inc – contains header files for specific components (e.g. Utilities, InputFiles)

lib – default target directory for library files

obj – default target directory for object files

prj – contains project files

*/prj – contains project files for specific components (e.g. Utilities, InputFiles)

src – contains source files

src/win – Windows specific source files*/src - contains source files for specific components (e.g. Utilities, InputFiles)

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 270 of 287

src

win

A.3

EGenProjectFiles

A.3.1

EGenProjectFiles are located in the EGen/prj and EGen/*/prj directories. These files can be used tofacilitate building EGen components in various environments.
Windows
A set of Visual Studio 2005, 2008, and 2010 files are provided. EGen.sln is the top level
solution file and includes all of the necessary .vcproj files.
Comment: Only the files for the newest Visual Studio are maintained.
provided for reference purposes only.



Older files are

U*x
Two sets of make files are provided to facilitate building the EGen components using a makeutility. The top-level makefile is known to work with various BSD-derived make utilities andthe GNU make utility. The make files in the GNUMake directory require GNU to make.
Comment: Only the files for GNUMake are maintained.
reference purposes only.

Other files are provided for

A.4

EGenInputFiles

A.4.1

EGenInputFiles are located in the EGen/flat_in directory. These files are text files containing rows oftab-separated data. The files are used by EGenLoader to create the data to populate the database andby EGenDriver components to generate valid input for Transactions. The generated data is based on
knowing the contents of the input files (“raw” material) and the overall scaling factors (Scale Factor,
Configured Customers, Initial Trade Days).

A.5

EGenSourceFiles

A.5.1

EGenSourceFiles are located in EGen/inc, EGen/*/inc, EGen/src and EGen/*/src and their associatedsub-directories.

A.5.2

EGenSourceFiles contain TPC-provided ANSI C++ code to be used in a compliant TPC-E implementation.
Functionality is provided to facilitate:population of a TPC-E compliant database

implementation of a TPC-E compliant environment

This functionality is described in subsequent sections.

A.6

EGenLoader

A.6.1

The task of populating a compliant TPC-E database can be broken into two parts:
generating compliant data records

loading the records into the database

Comment: The Sponsor is responsible for coming up with scripts to create the database and tables andto apply the required constraints.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 271 of 287

A.6.2

Data generation is a DBMS-neutral task, whereas database population is obviously very DBMSspecific. Therefore, EGenLoader is architected honoring this separation as follows. EGenSourceFiles
contain class definitions that provide abstractions of the TPC-E tables. These table classes are known
collectively as EGenTables and they encapsulate the functionality needed to generate the data for eachof the TPC-E tables. Many of the classes in EGenTables are dependent on EGenInputFiles for “rawmaterial” used in data record generation. EGenLoader therefore makes EGenInputFiles available to
EGenTables, and uses EGenTables to generate TPC-E compliant data records.

A.6.3

In order to support the DBMS-specific nature of loading the generated data, EGenLoader makes use ofa virtual base class CBaseLoader to “load” the data. This provides a controlled interface from the
DBMS-neutral data generation portion of EGenLoader to the DBMS-specific data loading portion of
EGenLoader. DBMS-specific code is encapsulated in subclasses that inherit from and provide an
implementation of the virtual CBaseLoader class. (Note: CBaseLoader is actually a template, where theone template parameter is the row type corresponding to the particular TPC-E table being loaded.)
EGenLoader provides two alternative implementations of CBaseLoader.

A.6.4

The first loader functionality provided by EGenLoader doesn’t actually load a database directly, butrather produces output flat files. One text file is produced for each TPC-E table. These files contain rowsof data values, where the data values are separated by “|”. To use this functionality, define thecompile-time variable COMPILE_FLAT_FILE_LOAD when building EGenLoader and use the “-lFLAT” switch when running EGenLoader.
This mode of loader functionality is designed to work with bulk-loader tools which populate a databasewith the contents of a set of flat files. Due to variations in the expected format of certain data types, it ispossible to configure EGenLoader via compile-time variables to change the format of certain data types
in the output flat files. The data types, compile-time variables and possible values are listed in thefollowing table:

Data Type

Compile-Time#defineDATETIMEDATETIME_FORMAT

See CDateTime::ToStr() in src/DateTime.cpp

DATE

DATE_FORMAT

See CDateTime::ToStr() in src/DateTime.cpp

TIME

TIME_FORMAT

See CDateTime::ToStr() in src/DateTime.cpp

BOOLEANBOOLEAN_TRUE

Any string constant representing a TRUE Boolean value. String
constants must be quoted.

BOOLEANBOOLEAN_FALSE

Any string constant representing a FALSE Boolean value. String
constants must be quoted.

Possible Values

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 272 of 287

A.6.5The second loader functionality provided by EGenLoader is for direct loading of a Microsoft SQL
Server database via the ODBC interface. To use this functionality define the compile-time variable
COMPILE_ODBC_LOAD when building EGenLoader and use the “-l ODBC” switch when running
EGenLoader.

A.6.6

EGenLoader can be extended by providing an implementation of the CBaseLoader template class in a
sub-class named CCustomLoader. To used this functionality define the compile-time variable
COMPILE_CUSTOM_LOAD and link with Sponsor-provided code that implements theCCustomLoader class when building EGenLoader, and use the “-p” option to pass parameters to thecustom loader.

A.6.7

A full listing of EGenLoader switches can be seen by building EGenLoader using EGenProjectFilesand then running EGenLoader with the “-?” switch.

A.7

EGenDriver

A.7.1

A TPC-E Test Sponsor is responsible for implementing a compliant TPC-E Driver (Clause 4 -- ). The TPC
provides EGenDriver to facilitate implementation of a compliant Driver and to standardize certain key
platform-independent parts of the Driver.

A.7.2

EGenDriver comprises the following three parts.


EGenDriverCE – any and/or all instantiations of the CCE class (see EGenSourceFiles CE.h andCE.cpp).



EGenDriverMEE – any and/or all instantiations of the CMEE class (see EGenSourceFiles MEE.hand MEE.cpp).



EGenDriverDM – the single instantiation of the CDM class (see EGenSourceFiles DM.h andDM.cpp).

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 273 of 287

A.7.3

EGenDriver, like EGenLoader, makes use of EGenInputFiles and EGenTables in data generation. This
provides data generation coherency between database population time and Test Run time.

A.7.4

The Sponsor is responsible for providing a suitable implementation of the Trade-Cleanup Transaction(see Clause 3.3.12). Trade-Cleanup may be implemented as a separate, standalone procedure or as partof EGenDriverDM.

A.8

EGenLogger

A.8.1

EGenLogger is used by EGenDriver and EGenLoader to log their configuration and any reconfiguration. Although not strictly required, the Test Sponsor is expected to override/provide a
SendToLoggerImpl implementation for recording EGenLogger’s output. For details see
EGen/inc/EGenLogger.h.

A.9

Implementing a CE using EGenDriverCE

A.9.1

Sending data to and receiving data from the SUT is very platform-specific functionality. Its
implementation depends on the underlying communication protocol and hardware used. Likewise,measuring the Transaction’s Response Time is also platform-specific – depending on what timing
mechanisms are provided by the underlying software and hardware.
However, the Transaction Mix (deciding which Transaction to perform next) and generating theTransaction input data is very platform-neutral. Therefore, EGenDriverCE encapsulates thisfunctionality and provides a standardized implementation for it across all TPC-E implementations.

A.10

Implementing a MEE using EGenDriverMEE

A.10.1

Sending data to and receiving data from the SUT is very platform-specific functionality. Its
implementation depends on the underlying communication protocol and hardware used. Likewise,measuring the Transaction’s Response Time is also platform-specific – depending on what timing
mechanisms are provided by the underlying software and hardware.
However, emulating the internal stock exchange functionality, and generating the Transaction input
data for Trade-Result and Market-Feed is very platform-neutral. Therefore, EGenDriverMEE
encapsulates this functionality and provides a standardized implementation for it across all TPC-E
implementations.
Comment: A proper MEE implementation must to able to adjust to changing rates of trade requests andbe able to turn-around trade requests into new Trade-Result Transactions in a timely fashion.
Similarly, a proper MEE implementation must be able to adjust to changing rates of Trade-Results andmust initiate Market-Feed Transactions in a timely fashion.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 274 of 287

A.11

Implementing a Data-Maintenance Generator using EGenDriverDM

A.11.1

Sending data to and receiving data from the SUT is very platform-specific functionality. Its
implementation depends on the underlying communication protocol and hardware used. Likewise,measuring the Data-Maintenance Transaction’s Response Time is also platform-specific – dependingon what timing mechanisms are provided by the underlying software and hardware.
However, generating the Transaction input data for the Data-Maintenance Transaction is very
platform-neutral. Therefore, EGenDriverDM encapsulates this functionality and provides a
standardized implementation for it across all TPC-E implementations.

A.12

EGenTxnHarness
EGenTxnHarness comprises any and/or all instantiations of:

CBrokerVolumeclass
excludingtheSponsorprovided
implementation
CBrokerVolumeDBInterface (see EGenSourceFile TxnHarnessBrokerVolume.h)of

CCustomerPositionclass
excludingtheSponsorprovided
implementation
CCustomerPositionDBInterface (see EGenSourceFile TxnHarnessCustomerPosition.h)of

CDataMaintenanceclass
excludingtheSponsorprovided
implementation
CDataMaintenanceDBInterface (see EGenSourceFile TxnHarnessDataMaintenance.h)of

CMarketFeed class excluding the Sponsor provided implementation of CMarketFeedDBInterface(see EGenSourceFile TxnHarnessMarketFeed.h)

CMarketWatchclass
excludingtheSponsorprovided
implementation
CMarketWatchDBInterface (see EGenSourceFile TxnHarnessMarketWatch.h)of

CSecurityDetailclass
excludingtheSponsorprovided
implementation
CSecurityDetailDBInterface (see EGenSourceFile TxnHarnessSecurityDetail.h)of

CTradeCleanup
classexcludingtheSponsorprovided
implementation
CTradeCleanupDBInterface (see EGenSourceFile TxnHarnessTradeCleanup.h)of

CTradeLookup
class
excludingtheSponsorprovided
implementation
CTradeLookupDBInterface (see EGenSourceFile TxnHarnessTradeLookup.h)of

CTradeOrder class excluding the Sponsor provided implementation of CTradeOrderDBInterface(see EGenSourceFile TxnHarnessTradeOrder.h)

CTradeResult class excluding the Sponsor provided implementation of CTradeResultDBInterface(see EGenSourceFile TxnHarnessTradeResult.h)

CTradeStatus class excluding the Sponsor provided implementation of CTradeStatusDBInterface(see EGenSourceFile TxnHarnessTradeStatus.h)

CTradeUpdateclass
excludingtheSponsorprovided
implementation
CTradeUpdateDBInterface (see EGenSourceFile TxnHarnessTradeUpdate.h)

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 275 of 287

of

A.13

Functional Implementation
The following diagram gives a high level overview of a sample implementation of the TPC-E
environment. A number of details have been omitted for clarity.

Figure A.b - High Level Overview of a Sample Implementation
TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 276 of 287

In the diagram above,

dotted “lines” with arrows between TPC Provided objects represent input parameters

dotted “lines” without arrows between TPC Provided objects represent input files fromEGenInputFiles

Solid “lines” with arrows are calls

1.

The Test Sponsor is responsible for implementing a Customer Emulator per Clauses 5.8.5 and A.8.
a.

DataFileManager is a class provided as part of EGen used for loading into memory the
EGenInputFiles used by other classes in EGen. The Test Sponsor is responsible for instantiatinga DataFileManager object correctly and passing a reference to it into the CCE constructor. See
EGen/InputFiles/inc/DataFileManager.h.

b.

TParameterSettings is a TPC provided structure that can be used to alter the behavior of
EGenDriver. Use of this structure for a compliant run is not required; it is provided to facilitate
prototyping and engineering work. See EGen/inc/DriverParamSettings.h.

c.

CCESUTInterface is a TPC provided pure virtual class that defines an interface used by the CCEclass. It is the Sponsor’s responsibility to subclass CCESUTInterface and provide the necessary
implementation. This implementation is responsible for sending a Transaction request to the
SUT, measuring the Transaction’s Response Time and logging all necessary data. A pointer tothe Sponsor’s implementation of the CCESUTInterface must be passed into the CCE constructor.
See EGen/inc/CESUTInterface.h.

d. CCE is a TPC provided class that must be used when implementing a Customer Emulator. It is
the Sponsor’s responsibility to provide a reference to a DataFileManager object and a pointer to a
CCESUTInterface object when constructing the CCE object. The process of running a test iseffectively looping around a call to CCE::DoTxn(). When DoTxn() is called, the CCE object will
determine which Transaction to perform, generate the necessary input data for the Transaction
and pass that data to the Sponsor’s implementation of CCESUTInterface for execution. See
EGen/inc/CE.h.
2.

The Test Sponsor is responsible for implementing a Market Exchange Emulator per Clauses 5.8.6
and A.10.
a.

DataFileManager is a class provided as part of EGen used for loading into memory the
EGenInputFiles used by other classes in EGen. The Test Sponsor is responsible for instantiating a
DataFileManager object correctly and passing a reference to it into the CMEE constructor. See
EGen/InputFiles/inc/DataFileManager.h.

b.

CMEESUTInterface is a TPC provided pure virtual class that defines an interface used by the
CMEE class. It is the Sponsor’s responsibility to subclass CMEESUTInterface and provide thenecessary implementation. This implementation is responsible for sending a Transaction request
to the SUT, measuring the Transaction’s Response Time and logging all necessary data. A
pointer to the Sponsor’s implementation of the CMEESUTInterface must be passed into the
CMEE constructor. See EGen/inc/MEESUTInterface.h.

c.

CMEE is a TPC provided class that must be used when implementing a Market Exchange
Emulator. It is the Sponsor’s responsibility to provide a reference to a DataFileManager object
and pointer to a CMEESUTInterface object when constructing the CMEE object. During a Test
Run, the Sponsor’s Market Exchange Emulator is responsible for accepting requests from theSponsor’s SendToMarket implementation running on the SUT and passing these requests to the
CMEE object via SubmitTradeRequest(). In addition, the Sponsor’s Market Exchange Emulator
is responsible for keeping a timer and calling CMEE::GenerateTradeResult() as necessary. See
EGen/inc/MEE.h.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 277 of 287

3.

The Test Sponsor is responsible for implementing functionality on the SUT to accept Transaction
request over a network connection from the Sponsor’s CCESUTInterface and CMEESUTInterface
implementations. Note that the diagram depicts individual network connections for eachTransaction type but the Sponsor is free to implement a single connection capable of handlingany/all types of Transactions. Upon receiving a Transaction request from the Driver, theSponsor’s code is responsible for calling DoTxn() on the appropriate EGenTxnHarness object (3a).
After returning from the call to DoTxn() the Sponsor’s code is responsible for sending theTransaction’s output back to the Driver.
See EGen/inc/TxnHarnessBrokerVolume.h – TxnHarnessTradeUpdate.h.
The Sponsor is responsible for providing implementations for the following classes used by
EGenTxnHarness.


CBrokerVolumeDBInterfaceCCustomerPositionDBInterface

CMarketFeedDBInterface

CMarketWatchDBInterface

CSecurityDetailDBInterface

CTradeLookupDBInterface

CTradeOrderDBInterface

CTradeResultDBInterface

CTradeStatusDBInterface

CTradeUpdateDBInterface


4.

A.14

These classes are responsible for implementing the Frames invoked by EGenTxnHarness.

CSendToMarketInterface is a TPC provided class that includes a pure virtual member function
SendToMarket(). The Sponsor is responsible for subclassing CSendToMarketInterface andproviding an implementation for SendToMarket(). This implementation is responsible for sending
trade requests to the Sponsor’s MEE implementation running on the Driver. A pointer to theSponsor’s implementation of CSendToMarketInterface must be passed into the constructor for the
EGenTxnHarness objects CTradeOrder and CMarketFeed.

TPC Defined Interfaces
Connector

Attachment Point

Interface (Class::Method)
CCE::DoTxn()

EGenDriver

Driving and Reporting

CMEE::SubmitTradeRequest()
CDM::DoTxn()
CDM::DoCleanupTxn()

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 278 of 287

CCESUTInterface::BrokerVolume()
CCESUTInterface::CustomerPosition()
CMEESUTInterface::MarketFeed()
CCESUTInterface::MarketeWatch()
CCESUTInterface::SecurityDetail()
EGenDriver

EGenDriver Connector

CCESUTInterface::TradeLookup()
CCESUTInterface::TradeOrder()CMEESUTInterface::TradeResult()
CCESUTInterface::TradeStatus()
CCESUTInterface::TradeUpdate()
CDMSUTInterface::DataMaintenance()
CDMSUTInterface::TradeCleanup()
CBrokerVolume::DoTxn()
CCustomerPosition::DoTxn()
CMarketFeed::DoTxn()
CMarketWatch::DoTxn()
CSecurityDetail::DoTxn()

EGenTxnHarness

EGenTxnHarness
Connector

CTradeLookup::DoTxn()
CTradeOrder::DoTxn()
CTradeResult::DoTxn()
CTradeStatus::DoTxn()
CTradeUpdate::DoTxn()
CDataMaintenance::DoTxn()
CTradeCleanup::DoTxn()
CBrokerVolumeDBInterface::DoBrokerVolumeFrame1()
CCustomerPositionDBInterface::DoCustomerPositionFrame1/2/3()
CMarketFeedDBInterface ::DoMarketFeedFrame1()
CMarketWatchDBInterface::DoMarketWatchFrame1/2/3()
CSecurityDetailDBInterface::DoSecurityDetailFrame1()
CTradeLookupDBInterface::DoTradeLookupFrame1/2/3/4()

EGenTxnHarness

Frame Implementation

CTradeOrderDBInterface::DoTradeOrderFrame1/2/3/4/5/6()
CTradeResultDBInterface::DoTradeResultFrame1/2/3/4/5/6()
CTradeStatusDBInterface::DoTradeStatusFrame1
CTradeUpdateDBInterface::DoTradeUpdateFrame1/2/3/4()
CTradeResultDBInterface::DoTradeResultFrame1/2/3/4/5/6()
CDataMaintenanceDBInterface::DoDataMaintenanceFrame1()
CTradeCleanupDBInterface::DoTradeCleanupFrame1()

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 279 of 287

Appendix B. EXECUTIVE SUMMARY STATEMENT
B.1

Sample Layouts

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 280 of 287

B.2

Sample Executive Summary Statement

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 281 of 287

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 282 of 287

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 283 of 287

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 284 of 287

Appendix C. TPC-E XML SCHEMA GUIDE
Overview

C.1

The schema of the ES.xml document is defined by the XML schema document tpce-es.xsd (available
from www.tpc.org). The ES.xml file must conform to the tpce-es.xsd (established by XML schema
validation).

Schema Structure

C.2

An XML document conforming to the tpce-es.xsd schema contains a single element named tpceResultof type RootType. Complex types are explained in the sections below. Simple types are not included
here, but can be found in tpce-es.xsd.
The RootType consists of the following attributes:

C.2.1

C.2.2

Attribute

Type

Description

SponsorName

string

The sponsor’s name.

ServerName

string

The name of measured server.

SpecVersion

SpecVersionType

TPC-E Specification version number under which
the benchmark is published

PricingSpecVersion

SpecVersionType

TPC-Pricing Specification version number underwhich the benchmark is published

ReportDate

date

The date that the result is submitted to the TPC.

RevisionDate

date

The date that a revision is submitted to the TPC, if
applicable; otherwise omitted.

AvailabilityDate

date

Availability Date (see TPC Pricing Specification)

tpsE

tpsEType

Reported Throughput in tpsE (see Clause 6.7.1)

PricePerf

PriceTypePrice/Performance Metric (see TPC Pricing
Specification)

Currency

CurrencyType

The currency in which the result is priced.

TotalSystemCost

PriceType

Total System Cost (see TPC Pricing Specification)

AuditorName

AuditorType

The name of the Auditor who certified the result.

Cluster

ClusterType“Y” or “N” indicating if the result was implemented
on a clustered server configuration.

SchemaVersion

SchemaVersionType

The schema version, initially “1.0”.

The RootType consists of the following elements:
Element

C.2.3

Type

Description

DBServer

DBServerType

The DBServer element contains information about
the database server.

RunData

RunDataType

The RunData element contains information about
the measured run.

Inventory

InventoryType

The Inventory element contains the system part list
and pricing data.

The DBServerType consists of the following attributes:
Attribute

Type

Description

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 285 of 287

C.2.4

DBNamestring

The name of the Database Management System(DBMS).

DBVersion

string

The version of the DBMS.

DBMiscInfo

stringAny miscellaneous information needed to indicate
precisely which version of the DBMS was tested(e.g., “Service Pack 1” or “Build 1298”).

OSNamestring

The name of the Operating System (OS) on which
the DBMS was running.

OSVersion

stringThe OS version.

OSMiscInfo

stringAny miscellaneous information needed to indicate
precisely which version of the OS was tested (e.g.,“Service Pack 1” or “Build 1298”).

ProcessorName

string

The processor name and type (e.g., “Intel Xeon 2.8
GHz”)

ProcessorCountpositiveInteger

The total number of processors in the Database
Server.

CoreCount

positiveInteger

The total number of cores in the Database Server.

ThreadCountpositiveInteger

The total number of threads in the Database Server.

MemorydecimalThe amount of memory (in GB) configured on the
Database Server.

InitialDBSize

positiveInteger

Initial Database Size in GB

RedundancyLevel

string

The Redundancy Level as defined in clause 7.5.5.4.

SpindleCountpositiveInteger

Priced number of Durable Media (disks) on the
Database Server.

The RunDataType consists of the following attributes:
Attribute

Type

Description

MeasurementInterval

TimeType

The length of the Measurement Interval in
hh:mm:ss.

RampupTime

TimeType

The length of the Ramp-up in hh:mm:ss.

RecoveryTime

TimeType

The Business Recovery Time in hh:mm:ss.

TotalTxns

positiveInteger

The number of Transactions completed within the
Measurement Interval.

The RunDataType contains the following elements:
Element

Type

Description

Broker-Volume

TxnDataType

Summary data for the Broker-Volume transactions.

Customer-Position

TxnDataType

Summary data for the Customer-Positiontransactions.

Market-Feed

TxnDataType

Summary data for the Market-Feed transactions.

Market-Watch

TxnDataType

Summary data for the Market-Watch transactions.

Security-Detail

TxnDataType

Summary data for the Security-Detail transactions.

Trade-Lookup

TxnDataType

Summary data for the Trade-Lookup transactions.

Trade-Order

TxnDataType

Summary data for the Trade-Order transactions.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 286 of 287

Trade-Result

TxnDataType

Summary data for the Trade-Result transactions.

Trade-Status

TxnDataType

Summary data for the Trade-Status transactions.

Trade-Update

TxnDataType

Summary data for the Trade-Update transactions.

Data-Maintenance

DmDataType

Summary data for the Data-Maintenancetransactions.

The TxnDataType consists of the following attributes:

C.2.5

Attribute

Type

DescriptionCount

positiveInteger

The number of transactions completed within the
Measurement Interval.

MixPercent

MixPercentType

Percentage of the Transaction Mix.

RTMin

RTTypeThe minimum Response Time.

RTMax

RTTypeThe maximum Response Time.

RTAvg

RTType

The average Response Time.

RT90thRTType

The 90th percentile Response Time.

The DmDataType contains the following attributes:

C.2.6

Attribute

Type

DescriptionCount

positiveInteger

The number of transactions completed within the
Measurement Interval.

RTMin

RTTypeThe minimum Response Time.

RTMax

RTTypeThe maximum Response Time.

RTAvg

RTType

The average Response Time.

TPC Benchmark™ E - Standard Specification, Revision 1.14.0 - Page 287 of 287