Teradata Director Program: Reference

Teradata Director Program
Reference
Release 14.00
B035-2416-071A
November 2011
The product or products described in this book are licensed products of Teradata Corporation or its affiliates.
Teradata, Active Enterprise Intelligence, Applications Within, Aprimo, Aprimo Marketing Studio, Aster, BYNET, Claraview, DecisionCast,
Gridscale, Managing the Business of Marketing, MyCommerce, Raising Intelligence, Smarter. Faster. Wins., SQL-MapReduce, Teradata Decision
Experts, Teradata Labs Logo, Teradata Raising Intelligence Logo, Teradata Source Experts, WebAnalyst, and Xkoto are trademarks or registered
trademarks of Teradata Corporation or its affiliates in the United States and other countries.
Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc.
AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc.
EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation.
GoldenGate is a trademark of Oracle.
Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company.
Intel, Pentium, and XEON are registered trademarks of Intel Corporation.
IBM, CICS, RACF, Tivoli, and z/OS are registered trademarks of International Business Machines Corporation.
Linux is a registered trademark of Linus Torvalds.
LSI is a registered trademark of LSI Corporation.
Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United
States and other countries.
NetVault is a trademark or registered trademark of Quest Software, Inc. in the United States and/or other countries.
Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries.
Oracle, Java, and Solaris are registered trademarks of Oracle and/or its affiliates.
QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation.
SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc.
SPARC is a registered trademark of SPARC International, Inc.
Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States
and other countries.
Unicode is a registered trademark of Unicode, Inc. in the United States and other countries.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other product and company names mentioned herein may be the trademarks of their respective owners.
THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN AS-IS BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
NON-INFRINGEMENT. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION
MAY NOT APPLY TO YOU. IN NO EVENT WILL TERADATA CORPORATION BE LIABLE FOR ANY INDIRECT, DIRECT, SPECIAL, INCIDENTAL,
OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS OR LOST SAVINGS, EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
The information contained in this document may contain references or cross-references to features, functions, products, or services that are
not announced or available in your country. Such references do not imply that Teradata Corporation intends to announce such features,
functions, products, or services in your country. Please consult your local Teradata Corporation representative for those features, functions,
products, or services available in your country.
Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated
without notice. Teradata Corporation may also make improvements or changes in the products or services described in this information at any
time without notice.
To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this
document. Please email: teradata-books@lists.teradata.com.
Any comments or materials (collectively referred to as Feedback) sent to Teradata Corporation will be deemed non-confidential. Teradata
Corporation will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform,
create derivative works of, and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, Teradata
Corporation will be free to use any ideas, concepts, know-how, or techniques contained in such Feedback for any purpose whatsoever, including
developing, manufacturing, or marketing products or services incorporating Feedback.
Copyright 1996-2011 by Teradata Corporation. All Rights Reserved.
Preface
Purpose
This book provides information about Teradata Director Program (TDP), which is a
Teradata Tools and Utilities product.
TDP is the Teradata software that resides on a mainframe client and provides channel
communication between applications and a Teradata Database.
Audience
This book is intended for use by:
System and application programmers
System administrators
Database administrators and relational database developers
Supported Releases
This book supports the following releases:
Teradata Database 14.0
Teradata Tools and Utilities 14.00
Teradata Director Program Version 14.00
To locate detailed supported-release information:

1
Go to http://www.info.teradata.com.
Under Online Publications, click General Search.
Type 3119 in the Publication Product ID box.
Under Sort By, select Date.
Click Search.
Open the version of the Teradata Tools and Utilities ##.##.## Supported Platforms and
Product Versions spreadsheet associated with this release.
The spreadsheet includes supported Teradata Database versions, platforms, and product
release numbers.
Teradata Director Program Reference
Preface
Prerequisites
Prerequisites
The following prerequisite knowledge is required for this product:
Familiarity with basic computer technology, database management systems, and utilities
that load and retrieve data.
Familiarity with system programming functions for z/OS or VOS3, depending on the
operating system that you are using to interface to the Teradata Database.
Changes to This Book

The following changes were made to this book in support of the current release. Changes are
marked with change bars. For a complete list of changes to the product, see the Release
Definition associated with this release.
Date and Release
Description
November 2011
14.00
Updated Teradata Director Program Reference to reflect Teradata products

added and updated for Teradata Tools and Utilities Release 14.00.
Descriptions of exit versions enhanced.
Documentation now clarifies that an expired password does not prevent a
logon when TDP has authenticated the Database userid. See User Logon
Exit Interface on page 52.
Updated DISPLAY CELLS with information on initial cell counts. See
DISPLAY CELLS on page 119.
Added content to clarify the descriptions of IRF sessions.
Added Security Considerations on page 21. Renamed and reorganized
Chapter 4.
Updated information on creating your own TDPPARM. See Creating Your
Own TDPPARM on page 71.
Added content about the relationship of multiple TDPs and Logical Hosts.
See TDPs Role in a Teradata System on page 19.
Updated Configuring the Mainframe Operating System on page 25.
Added StatementError, FetchRowCount, and ClientAttributes codes to
tables for Parcel Flavors on page 248 and Parcel Types on page 250.
Also added ClientAttributes. See ClientAttributes on page 257, deleted
Abort, deleted RunResponse, and added Individual Columns section to
Sessions discussion. See Sessions on page 30.
TDP support for the AlwaysOn Redrive feature documented. See
SessionOptions on page 269.
Moved content of previous INITIAL commands table into Table 2: TDP
Operator Commands on page 82.
Preface
Additional Information
Additional information that supports this product and Teradata Tools and Utilities is available
at the web sites listed in the table that follows.
Type of Information
Description
Access to Information
Release overview
Use the Release Definition for the following

information:
1 Go to http://www.info.teradata.com.
Overview of all of the products in the

release
Information received too late to be
included in the manuals
3 Type 2029 in the Publication Product ID box.
Late information
Operating systems and Teradata

Database versions that are certified to
work with each product
Version numbers of each product and
the documentation for each product
Information about available training
and the support center
Additional product
information
Use the Teradata Information Products web

site to view or download specific manuals
that supply related or additional
information to this manual.
2 Under Online Publications, click General Search.

4 Click Search.
5 Select the appropriate Release Definition from
the search results.
2 Under the Online Publications subcategory,
Browse by Category, click Data Warehousing.

3 Do one of the following:
For a list of Teradata Tools and Utilities

documents, click Teradata Tools and Utilities,
and then select an item under Releases or
Products.
Select a link to any of the data warehousing
publications categories listed.
CD-ROM images
Access a link to a downloadable CD-ROM

image of all customer documentation for
this release. Customers are authorized to
create CD-ROMs for their use from this
image.
2 Under the Online Publications subcategory,
Browse by Category, click Data Warehousing.

3 Click CD-ROM Images.
4 Follow the ordering instructions.
Ordering
information for
manuals
Use the Teradata Information Products web

site to order printed versions of manuals.
2 Under Print & CD Publications, click How to
Order.
3 Follow the ordering instructions.
Preface
Type of Information
Description
Access to Information
General information
about Teradata
The Teradata home page provides links to

numerous sources of information about
Teradata. Links include:
1 Go to Teradata.com.
2 Select a link.
Executive reports, case studies of

customer experiences with Teradata,
and thought leadership
Technical information, solutions, and
expert advice
Press releases, mentions, and media
resources
Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Supported Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Changes to This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Chapter 1:
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
TDPs Role in a Teradata System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Logical Hosts, Channel Processors, and Session Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Call-Level Interface (CLI) in a Teradata System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Teradata Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Teradata Session Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Externally Coordinated Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chapter 2:
Configuration and Operational Considerations . . . . . . . . . . . . . . . . . 25
Configuring Logical Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Configuring the Mainframe Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Installing TDP and CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Configuring TDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
TDP Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
TDP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
TDP Virtual Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Table of Contents
Chapter 3:
Performance Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
DBCTSTMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
General Tuning Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
z/OS and VOS3 Performance Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
CP Shutdown Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Logoff Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Security Violations Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
TDP Shutdown Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
Structure-protocol Termination Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
z/OS and VOS3 Tuning With the HSI System Parameter Block . . . . . . . . . . . . . . . . . . . . . . . .46
z/OS Tuning With I/O Mode Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Chapter 4:
Customer Exits and Teradata Userid Authentication . . . . . . . . . .49
User Address Space Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
User Logon Exit Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
TDP User Transaction Collection Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
User Security Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
External Security Manager Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Chapter 5:
The Release Tape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
TDPXRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
Chapter 6:
TDP Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Starting a TDP Under z/OS or VOS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Initializing a TDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
Entering TDP Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Entering TDP Commands on z/OS and VOS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Entering TDP Commands from CLIv2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Table of Contents
Types of TDP Command Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

TDP Operator Message Character Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Shutting Down a TDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Regulating Authority to Issue TDP Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Session Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Chapter 7:
TDP Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
TDP Operator Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
ADD CELLS/XMSCELLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
ATTACH CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
ATTACH IFP (Deprecated by ATTACH CP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
AUTHORIZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
COMMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
COMMIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
DETACH CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
DETACH IFP (Deprecated by the DETACH CP command) . . . . . . . . . . . . . . . . . . . . . . 98
DISABLE IRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
DISABLE LGUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
DISABLE LOGONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
DISABLE POOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
DISABLE POOL DETAIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
DISABLE POOL STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
DISABLE SECLOGON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
DISABLE SESSION DETAIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
DISABLE SESSION RESERVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
DISABLE SESSION STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
DISABLE SMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
DISABLE TDPSTATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
DISABLE TEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
DISABLE TIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
DISABLE TMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
DISABLE TRAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
DISABLE UAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
DISABLE USEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
DISPLAY CCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
DISPLAY CELLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
DISPLAY CHECKSUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
DISPLAY CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
DISPLAY IFP (Deprecated by the Display CP command) . . . . . . . . . . . . . . . . . . . . . . . 129
Table of Contents
DISPLAY INDOUBT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131

DISPLAY JOB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
DISPLAY LIMIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
DISPLAY MODULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
DISPLAY POOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
DISPLAY QUEUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
DISPLAY SERVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
DISPLAY SESSIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
DISPLAY SMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
DISPLAY SP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
DISPLAY STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
DISPLAY TDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
DISPLAY TDPSTATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
ENABLE IRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
ENABLE LGUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
ENABLE LOGONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
ENABLE POOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
ENABLE POOL DETAIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
ENABLE POOL STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
ENABLE SECLOGON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
ENABLE SESSION DETAIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
ENABLE SESSION RESERVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165
ENABLE SESSION STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
ENABLE SMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
ENABLE TDPSTATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
ENABLE TEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170
ENABLE TIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
ENABLE TMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172
ENABLE TRAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
ENABLE UAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
ENABLE USEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176
INITIAL CCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
INITIAL DLYTIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
INITIAL IACMODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
INITIAL IOBUFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
INITIAL IOMODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
INITIAL JOBWAIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184
INITIAL LSQA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
INITIAL MSGPREF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186
INITIAL OSSISUFX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187
INITIAL PCSUFX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
INITIAL TRUNCRSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
LOGOFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
10
Table of Contents
LOGOFF POOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MODIFY POOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MODIFY SECLOGON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RESOLVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ROLLBACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SET CHARSET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SET CHECKSUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SET COMCHAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SET LIMIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SET MAXSESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SET STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SET USERCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SET USERID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SHUTDOWN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
START CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
START IFP (Deprecated by the START CP command) . . . . . . . . . . . . . . . . . . . . . . . . .
START POOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
STOP CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
STOP IFP (Deprecated by the STOP CP command) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
STOP POOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
192
193
194
195
196
197
198
200
201
202
203
204
205
206
208
210
212
214
223
224
225
Appendix A:
Channel Processor Device and Channel Error Log . . . . . . . . . . . 227
Sample EREP Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Record Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Sense Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Appendix B:
Overview of SET USERCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Defining a Character Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHARSET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
END . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MONOCASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SANITIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UNICODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
233
235
236
239
240
242
244
11
Table of Contents
Appendix C:
Parcel Flavors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
Parcel Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
Parcel Flavors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248
Parcel Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
Parcel Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
Abrt2PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
Cancel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256
ClientAttributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257
Cmmt2PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258
Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258
FMRunStartup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259
IVRunStartup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
Logoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
Logon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261
Multi-TSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262
NOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263
OffsetPosition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263
ResultSet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264
ResultSet Cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265
ResultSet Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .266
Rewind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267
RowPosition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267
Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .268
RunStartup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269
SessionOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269
UserNameRequest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271
UserNameResponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272
VoteRequest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273
VoteTerm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274
Appendix D:
How to Read the Syntax Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .275
Syntax Diagram Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .275
12
Table of Contents
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
13
Table of Contents
14
List of Figures
Figure 1: Typical Teradata System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figure 2: Sample EREP Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
15
List of Figures
16
List of Tables
Table 1: Function Codes Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Table 2: TDP Operator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Table 3: Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Table 4: Original Parcel Header (TPH0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Table 5: Alternate Parcel Header (TPH1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Table 6: Parcel Flavors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Table 7: Request Parcel Flavors, Names, and Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Table 8: Response Parcel Flavors, Names, and Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Table 9: Abrt2PC Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Table 10: Cancel Parcel Filed Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Table 11: ClientAttributes Parcel Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Table 12: Character Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Table 13: Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Table 14: Cmmt2PC Parcel Field Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Table 15: FMRunStartup parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Table 16: IVRunStartup Parcel Field Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Table 17: Logoff Parcel Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Table 18: Logon Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Table 19: Multi-TSR Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Table 20: NOP Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Table 21: OffsetPosition Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Table 22: ResultSet Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Table 23: ResultSet Cursor Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Table 24: ResultSet Selection Parcel Field Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Table 25: Selection Cursor Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Table 26: Rewind Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Table 27: RowPosition Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Table 28: Run Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Table 29: RunStartup Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Table 30: SessionOptions Parcel Field Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Table 31: UserNameRequest Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Table 32: UserNameResponse Parcel Field Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
17
List of Tables
Table 33: VoteRequest Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273

Table 34: VoteTerm Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274
18
CHAPTER 1
Introduction
This chapter presents an overview of Teradata Director Program (TDP), which is installed on
an IBM compatible mainframe computer running the z/OS or VOS3 operating systems. The
intention of this chapter to provide the vocabulary and background necessary to understand
the information in subsequent chapters.
This chapter describes the following:
TDPs Role in a Teradata System
Security Considerations
Logical Hosts, Channel Processors, and Session Processors
Call-Level Interface (CLI) in a Teradata System
Teradata Sessions
Teradata Session Requests
Externally Coordinated Commit

As shown in Figure 1, Teradata supports a variety of clients that can be attached using either a
mainframe channel or a network connection. Client applications communicate with the
Teradata Database to load, update, and query data that it holds. This book describes the
software interface for mainframe clients.
19
Chapter 1: Introduction
Figure 1: Typical Teradata System
Teradata Database
Mainframe 1
Mainframe 2
VM Client:
- VM Operating System
- TDP
- CLI
Network-Attached Clients
MVS Client:
- MVS Operating System
- TDP
- CLI
FZAPN075
TDP provides a high-performance communication interface between mainframe applications

and the Teradata Database. One Teradata Database is logically subdivided into multiple
Logical Hosts, each of which can be connected to one and only one TDP: any mention of a
Teradata Database in TDP documentation implies one of these Logical Hosts, on whatever
physical Database server it may reside. Every mainframe system connected to a Teradata
Database has at least one TDP associated with it. Therefore, a mainframe connected to more
than one Teradata Database has more than one TDP. The connections and so the TDPs may be
on any number of IBM LPARsrunning MVS. On any MVS, any number of TDPs, each of any
release, may be started simultaneously. The operation and resources, of every TDP are
completely independent of any others. The TDP executable modules for a release may be
shared by any number of TDPs of that same release, except that those TDP modules in the
MVS LPA for one release must be differentiated from the same modules for a different release
using different one character suffixes.
Each TDP is identified by a tdpid, which is meaningful only within the mainframe system. On
z/OS and VOS3, a tdpid corresponds to a Subsystem id so consists of four characters, the first
three of which are 'TDP' and the fourth uniquely differentiates TDPs on that system. Each
TDP operates in its own address space.
TDP displays messages and accepts commands from operator consoles, or software that
emulate such consoles. Under z/OS and VOS3, TDP-defined records are written to the System
Recording Facility (SMF). Standard records are written to LOGREC for problems with the
devices used to communicate with the Teradata Database. Under z/OS and VOS3, internal
diagnostics can utilize the Generalized Trace Facility (GTF).
20
TDP communicates with the Teradata Database from its address space, so its execution
environment is independent of any applications using the Database. Specifically note the
following:
TDP executes on MVS as an APF authorized program but limits its use of system
authorities to those required by specific operating system services.
TDP accesses only datasets specified in the Job Control Language used to start TDP.
Standard dataset access controls are not circumvented. Only standard dataset access
methods are used.
For communication with the Teradata Database using channel devices, either STARTIO,
EXCPVR, or EXCP is used, as controlled by TDP commands when TDP begins execution.
Neither application SQL data nor Teradata Database logon passwords are retained beyond
their need, nor are they passed to other address spaces. Such information is not included
in any internal trace. The exception is incidental storage capture by system storage dump
processing.
TDP does not inspect or alter the application's SQL request or response data.
TDP communicates with applications using the Teradata Database in their own address spaces
using routines in commonly addressable storage such as the MVS Link Pack Area.
Applications call CLIv2 routines, which in turn communicate to TDP using a state switch.
After a TDP routine in the application address space receive control in TDP's state, access
to application storage for the request is serialized, validated, and performed only with the
same access capabilities as the application itself possesses.
The TDP copy of the application's request is protected from any access or modification by
the application.
No application resources except storage explicitly designated by the application is

inspected or altered. No datasets are accessed in the application address space. No I/O is
performed to any device. No communication facility, such as TCP/IP, is invoked.
No changes are made to the application's environment. No authorization is extended

beyond TDP's routines.
Information is passed only to the TDP address space. No other address space is inspected
or passed any information.
Communication with the TDP address space is serialized, validated, and performed only
with the same access capabilities as the application itself possesses.
Logical Hosts, Channel Processors, and Session

Processors
While the Teradata Database is a complex system, three aspects are of primary concern to
TDP.
21
Logical Host
A Logical Host is a Database configuration of related resources. Each TDP can use the
resources of only one Logical Host. A Logical Host is identified by a Host Number, an
arbitrary number between 1 and 1023. Each also has a Host Type, which identifies client
characteristics (such as a default character set type and the structure of numeric data). For
IBM mainframes the Host Type is designated by 'IBM', which is assigned the value zero. The
Host Number is added to the Host Type to create a Logical Host Id. TDP is informed of the
Logical Host Id when it establishes communication with the Database.
Channel Processor
A Channel Processor (CP) is a pair of devices on the Teradata Database that are attached to a
mainframe channel and used by TDP to communicate with the Database. Many CPs can be
used for communication between a Database and a TDP. The implementation of a CP can
vary on different Databases, but the behavior of all CPs is the same. For example, on a DBC/
1012, an IFP implements a CP, while on a System 3600, an MCCA on an AP implements a CP.
Because the original implementation of an IFP embodied the functions of a CP, the pair of
devices were referred to as an IFP.
The devices composing a CP are known to the operating system.
From TDP's perspective, there are two types of CPs, characterized by their communication
protocol with TDP: the original Channel Interface Controller (CIC) and the newer Channel
Communication Unit (CCU).
Session Processor
A Session Processor (SP) is a logical component on the Teradata Database that provides
session capacity, which is the connection between an application and the Database. Each SP
allows a fixed number of sessions, but many SPs can be used by a TDP. The implementation of
an SP can vary on different Databases, but the behavior of all SPs is the same. For example, on
a DBC/1012, an IFP implements an SP, while on a System 3600, a PE implements an SP.
No aspect of an SP is known to the client operating system.

CLI provides the interface for mainframe applications to communication with one or more
Teradata Databases. CLI is a set of subroutines that are called by an application, so CLI
executes in the application's address space or virtual machine. Under MVS, applications
running as IBM CICS or IBM IMS transactions are also supported by CLI.
Applications written in Assembler, PL/I, COBOL, C, C++, or other languages that have a
CALL-type statement and use standard operating system linkage conventions (such as
FORTRAN or PASCAL) call CLI routines directly. After the program is compiled, a CLI stub is
included and a load module is created. When the application calls a CLI routine, the CLI stub
22
Teradata Sessions
dynamically loads the CLI runtime, which sends the request to or receives a response from
TDP.
The current application programming interface is provided by a CLI known as CLIv2. While
an older version exists, it is deprecated for new application development. For complete
information about CLIv2, refer to Teradata Call-Level Interface Version 2 Reference for
Mainframe-Attached Systems.
Teradata Sessions
A Teradata session is a logical connection between a CLIv2 application and the Teradata
Database. A session permits an application to send requests to, and receive associated
responses from, the Teradata Database. An application can establish any number of
concurrent sessions.
A session is explicitly logged on and off. The session is established when the Teradata Database
accepts the user name and password of the user. The session is discarded when explicitly
logged off by the application, when the application ends, when TDP is restarted, or when a
TDP command ends the session.
Each session is identified to the application and to the Teradata Database by a session number.
A session number is assigned by TDP and is unique for a given TDP.
Teradata Session Requests

A Teradata request is sent to the Teradata Database by a CLIv2 application using an
established Teradata session. The response to a request is created by the Teradata Database.
Each request is identified to the application and to the Teradata Database by a request number.
A request number is assigned by TDP and is unique for a given session. It is known to the
Teradata Database
A request either succeeds or fails. If any part of the request fails, any effects are backed out
the database remains unchanged.
The response is normally received sequentially by the application, but direct access to selected
portions of the response is also supported. While up to sixteen completed responses can exist
for a session at any one time, only one request can be active for a session at any time.

It is possible for a single application to update multiple databases. For example, in a transfer of
funds, an application could withdraw money from a bank account on one database and
deposit it into another account on a different database. As an option, an application can use
an externally coordinated commit process to ensure that updates are applied consistently to all
23
affected databases. One of the methods used to accomplish this process is the two-phase
commit (2PC) protocol, supported by the Teradata Database.
With the 2PC protocol, an application can update multiple databases in the same logical unit
of work, with a coordinator such as IBMs CICS and IMS transaction processing systems
controlling the process. The coordinator uses the 2PC protocol to ensure that all the updates
for all the participants in the logical unit of work either commit or roll back. Within a
Teradata Database session that is using the 2PC protocol, there is a time when it is in an indoubt state, awaiting final instructions from the coordinator on whether to commit or roll
back the updates. If a failure in the coordinator or another part of the system occurs during
this in-doubt period, the Teradata Database cannot unilaterally decide to commit or roll back
the updates. In the event that automatic in-doubt resolution is not possible because of an
extended coordinator outage, manual resolution of the in-doubt sessions can be necessary.
This is because these in-doubt sessions can hold locks on data base objects that block the
progress of other applications that are trying to access those objects.
For details of the Teradata support for IBMs CICS or IMS, refer to the following books:
24
CICS Interface for Teradata
IBM IMS/DC Interface for Teradata
CHAPTER 2
Configuration and Operational

Considerations
This chapter presents an overview of configuration of resources related to TDP and significant
aspects of TDP operation. The intention of this chapter to provide a basic understanding of
the operational impact of TDP.
This chapter describes the following:
Configuring Logical Hosts
Configuring the Mainframe Operating System
Installing TDP and CLI
Configuring TDP
TDP Commands
TDP Messages
Sessions
Requests
TDP Virtual Storage
Configuring Logical Hosts

Logical Host Ids are defined and SPs associated with them using the Teradata Database
Configuration Utility, referred to in Utilities, B035-1102. The Host Type Designator is always
'IBM'. In that document, SPs are referred to as PEs.
CPs are associated with a Logical Host using the Teradata Database Parallel Upgrade Tool,
refer to the appropriate book.
Parallel Upgrade Tool (PUT) for UNIX MP-RAS and Linux User Guide
Parallel Upgrade Tool (PUT) for Microsoft Windows User Guide
Configuring the Mainframe Operating System

For details on configuring the operating system, refer to the appropriate book.
Teradata Tools and Utilities Installation Guide for IBM z/OS
25
Chapter 2: Configuration and Operational Considerations

That document describes changes to MVS to define CP devices, the TDP subsystem, TDP Job
Control Language (JCL), APF authorization, the Linklist, and Link Pack Area (LPA)
requirements for each version of TDP to be run.

For details on installing TDP and CLI, refer to the book appropriate for the mainframe
operating system.
Configuring TDP
TDP is configured through its commands. TDP commands which are always issued when
TDP is started can be specified in a dataset allocated by a z/OS or VOS3 TDPPARM Data
Definition (DD) statement in the TDP Job Control Language (JCL) or FILEDEF for
TDPPARM. Such commands fall into two general categories: those that can only be issued
from TDPPARM and those that can be issued anytime.
Those commands that can only be issued from TDPPARM have a unique command verb,
INITIAL (refer to TDP Operator Command Descriptions on page 81 for a complete
description). INITIAL commands can only be issued from TDPPARM because their settings
are necessary for TDP to initialize. Since all settings have defaults, no INITIAL commands are
required. But two such commands are often used.
The mode of communication with the Teradata Database can be specified by the INITIAL
IOMODE command.
On z/OS and VOS3, EXCPVR is the default because it is a general interface, but on
z/OS, IOSDRIVR is recommended (it is not the default only because it is an
undocumented z/OS interface, even though it has been fully stable and unchanged for
many years).
On z/OS, the version of the TDP Link-pack routines needed to communicate with
applications can be specified if multiple versions of TDP are installed on the system. The
INITIAL OSSISUFX and INITIAL PCSUFX commands can be used to specify the one
character suffix for the versions that match the TDP version. The same suffix character is
normally used on both commands.
All other TDP commands can be issued anytime TDP is running (refer to Chapter 7: TDP
Commands for descriptions of all commands). Including those always issued in TDPPARM
eliminates the need to manually issue the same commands every time TDP is started. Two
commands are almost always specified.
26
One START CP command is included for each CP configured for the Logical Host. While
not all CPs configured for the Logical Host need be STARTed, there is no purpose in not
doing so.

TDP Commands
The RUN command is included as the last command to begin TDP processing.
Once the typical workload has been established, it is common to adjust the virtual storage
used by TDP storage cells by including the TDP commands ADD CELLS and ADD
XMSCELLS.
TDP Commands
TDP commands can be issued from TDPPARM during initialization, from operator consoles
(or programs that simulate consoles), for z/OS and VOS3 from the Subsystem Interface or the
system MODIFY command, by the Teradata DBCCMD application, or from CLIv2
applications using the DBCHCL Command function. When issued from a z/OS or VOS3
console, responses are returned to that console (on z/OS, both one and four byte console ids
are supported).
Just as all work for TDP, commands require TDP cells for processing. A shortage of XMS cells
will force TDP to convert a command issued from the Subsystem Interface to the system
MODIFY command. If such a shortage prevents command processing, the system MODIFY
command can be used to issue TDP commands. A shortage of non-XMS cells can prevent all
TDP command processing or the responses to command. A shortage of any cell type will have
previously generated a message as described in the Messages Having Operational Impact
section later in this chapter. Since command processing can be affected, such shortages should
be dealt with as they occur.
TDP Messages
TDP issues messages in response to commands and to inform the operator of events of
interest. Since there is rarely any reason to do so, TDP provides no mechanism to periodically
issue commands, but z/OS and VOS3 Job Entry Subsystem (JES) commands, automated
operations software, or programs that simulate consoles can periodically issue TDP
commands. The following other aspects of TDP messages are presented:
Routing and Descriptor Codes
Messages Requiring Replies
Messages Having Operational Impact
Routing and Descriptor Codes

On z/OS and VOS3, the following standard routing and description codes are used.
Routing Code
Use
Action
Operator Information
27

TDP Messages
Routing Code
Use
Security
11
Programmer Information
Descriptor Code
Use
Action
System Status
Task Related
Messages with descriptor code 2 are retained on operator consoles until TDP deletes them,
unless the system's action message retention facility is disabled (using the system K
M,AMRF=N command).
Messages Having Operational Impact

While many TDP messages are informational and require no actions, several reflect
conditions that can adversely impact TDP so might warrant some corrective action.
Operational procedures or automated operations software should consider such messages.
Since the types and quantity of processing performed by TDP can vary widely, its use of
virtual storage also varies. TDP separates its use of virtual storage into various sizes of
cells, with the number of cells of each size selected when TDP initializes. If all cells of a
particular size are exhausted, some aspect of TDP will either dynamically allocate a new
cell or wait for other TDP processing to release a cell of that size. If dynamically obtained
the cell will be freed when its use is complete. Either action can affect performance so is
indicated by the following message:
TDP0021 **WARNING** 100% OF nnnnn BYTE CELLS ARE IN USE
The shortage can be addressed by using the TDP ADD CELLS command to increase the
number of cells of that size. Using z/OS, a second type of some size cells, known
collectively as XMS cells, exist for use in communicating with application address spaces.
Should a shortage of these cells occur, that request or response is delayed until other
processing frees an XMS cell of the required size. Such delays are indicated by one of the
following messages:
TDP0201 **WARNING** 100% OF INITIAL XMS CELLS ARE IN USE
TDP0202 **WARNING** 100% OF ADDITIONAL XMS CELLS ARE IN USE
The first indicates that one of the three sizes of XMS cells is unavailable; the second
indicates that the largest of the three is unavailable. The shortage can be addressed by
using the TDP ADD XMSCELLS command to increase the number of cells of that size.
28
Communication with the Teradata Database can be interrupted if an individual CP fails to

respond, or if the Database crashes or is manually restarted. Since each CP is independent
of the others, each will produce the following message if communication using it is lost:

TDP Messages
TDP2202 "cpname" IS WAITING FOR COMMUNICATION TO BE ESTABLISHED
The loss of only some CPs can affect requests that are active on that CP but otherwise only
reduces performance. If all CPs fail, the following message results:
TDP1700 COMMUNICATION LOST WITH THE TERADATA DATABASE
If only some CPs fail, this message will not be produced, indicating that performance can
be degraded. No message is produced when an individual CPs starts processing again, but
the TDP DISPLAY CP command can be used to ascertain their status. Periodically (as
specified by the TDP INITIAL DLYTIME command) if communication has not been reestablished, the following reminder occurs:
TDP1701 MINUTES SINCE TERADATA DATABASE COMMUNICATION LOST: min
The time taken by the Teradata Database to complete its restart varies, but the more time
that elapses the more likely that a more serious Database problem exists. When the
Database does complete its restart and any CP begins processing, the following message is
produced:
TDP1702 TERADATA DATABASE COMMUNICATION HAS BEEN RE-ESTABLISHED
Again, this does not imply that every CP is functional, only that at least one is. The failure
of an SP forces a Database restart and if the SP remains down after the restart, TDP will
switch sessions on the down SP to other SPs. If there is insufficient session capacity then
the following message results:
TDP1706 INSUFFICIENT SP CAPACITY FOR EXISTING SESSIONS
No new sessions are permitted until all existing sessions are switched to functional SPs.
The following message indicates that this has been accomplished and new sessions are
again permitted:
TDP1708 SUFFICIENT SP CAPACITY FOR EXISTING SESSIONS
It is also possible that unrelated to a Database restart, a CP problem might be detected. A

physical permanent I/O error is indicated by:
TDP2203 "cpname" UNUSABLE -- PERMANENT I/O ERROR
while a logical failure of the internal communication protocol is indicated by one of the
two following messages:
TDP2207 "cpname" UNUSABLE -- TERADATA DATABASE PROTOCOL-VIOLATION
TDP2208 "cpname" UNUSABLE -- CLIENT PROTOCOL-VIOLATION
In addition to explicit events, TDP can detect implicit communication problems. If an

internal request sent to recover from a loss of communication with the Database is judged
to be taking excessive time and another functional CP exists, the following message is
issued and the request is resent using another CP:
TDP1788 "cpname" ASSUMED TO HAVE HUNG ON THE CHANNEL
If a number (as indicated by the DISPLAY LIMIT NORESP command) of consecutive

requests have been sent on a CP without any responses received, the CP is judged to be
unresponsive. One of the following messages is issued and subsequent requests are sent
using any functional CP until this one begins responding. Requests already sent are
unaffected and will remain outstanding until their responses are received.
TDP2211 "cpname" HAS BEEN QUIESCED: UNRESPONSIVE
29

Sessions
TDP2212 "cpname" HAS BEEN QUIESCED: UNRESPONSIVE
The TDP2212 message will be held on the operator console until either manually deleted,
the CP is again responsive, the CP is STOPped, or TDP ends. This is the preferred message
because it is held on the z/OS or VOS3 console for the duration of the problem. The
TDP2211 message, which is not held on the console, is issued only if internal TDP
conditions prevent the preferred message.
If either a response is eventually received, the SET LIMIT command raises the limit, or a
Database restart occurs, use of the CP is resumed after the following message is issued:
TDP2213 "cpname" IS NO LONGER QUIESCED: reason
The server can reject an attempt to establish a session because the Teradata userid is
unknown or the supplied password is invalid. Such a Teradata security violation is
indicated by:
TDP0907 type VIOLATION FOR JOB: jobname, SESSION: number
If a TDP logon exit rejects the session it issues the following message:
TDP0908 messagetext
Exceeding certain internal TDP limits may impact message processing. If TDP is unable to
retain the system's identity for an action message the system cannot be told to delete it.
This situation is indicated by:
TDP0376 UNABLE TO RETAIN OPERATOR MESSAGE IDENTITIES, CODE(code)
If TDP is unable to retain the system's identity of the source of a TDP command the
response cannot be routed back to it. This situation is indicated by one of the following
messages:
TDP0312 UNABLE TO RETAIN ORIGINATING CONSOLE INFORMATION
TDP0203 UNABLE TO RETAIN ORIGINATING CONSOLE INFORMATION
Messages Requiring Replies

Operator replies are only required by TDP if any TDPPARM command contained an error.
The operator is prompted to either shutdown TDP or ignore the error(s) and continue.
Sessions
TDP establishes sessions at the request of the application. The following aspects of sessions are
presented:
30
Session Information
Diagnostic Status and Detail
Session Pools
Automatic logoff
In-Doubt Session Resolution
Replication

Sessions
Session Information
When a session is established, information is added to either individual columns in
DBC.SessionTbl and DBC.EventLog, the LogonSource column in various views (such as
dbc.LogOnOff and dbc.SessionInfo), or both by the Teradata Database depending on its
version.
Individual Columns
The session information consists of multiple columns, each containing a specific value. The
following columns may contain values:
Column
Description
ClientConnectionType
Communication type, with the unsigned integer 2 indicating a channel

connection
ClientOsName
Canonical operating system designation, with the EBCDIC value 'MVS'
ClientTdHostName
TDPid as an EBCDIC value
ClientJobName
jobname as an EBCDIC value
ClientEnvName
Environment, as an EBCDIC value of 'BATCH', 'TSO', 'CICS', or 'IMS'
ClientUserIdSecProd
Operating system userid from a security product as an EBCDIC value, if a

security product exists
ClientGroupSecProd
Group from a security product as an EBCDIC value, if a security product exists
ClientProgramName
Application program name as an EBCDIC value
ClientCoordName
Optional coordinator name as an EBCDIC value
ClientTransactionId
Transaction identifier as an EBCDIC value, if the environment is 'CICS' or

'IMS'
ClientTerminalId
Terminal identifier as an EBCDIC value, if the environment is 'CICS' or 'IMS'
ClientUserOperId
the user or operator identifier as an EBCDIC value, if the environment is

'CICS' or 'IMS'
ClientJobId
job id as an EBCDIC value
ClientTDPReleaseId
TDP release as an EBCDIC value
ClientCLIv2ReleaseId
CLIv2 release as an EBCDIC value
ClientSessionDesc
Optional CLIv2 application Session-desc specification as an EBCDIC value
ClientWorkload
Optional CLIv2 application Workload specification as an EBCDIC value
LogonSource Column
The session information consists of two types of data:
positional fixed-length items
optional self-defining variable-length items
31

Sessions
Positional Fixed-Length Items

TDP provides system-dependent information in the LogonSource column, consisting of the
following series of eight-character values, each left-justified and padded on the right with
blanks:
Operating System Name (MVS or VOS3)
TDPid
Jobname (z/OS jobname)
Environment Name (either BATCH, TSO, IMS, or CICS for z/OS)
Userid from Security Product (blank if no such product)
Group from Security Product (blank if no such product)
Program Name - contains either the executable application name or an identifier provided
by the application using the CLIv2 Workload specification. Since it cannot be determined
which is present, the value is deprecated. The executable application name is reliably
provided by the later Actual Program Name item.
Coordinator name (omitted if not for CICS or IMS)
Transaction identifier (omitted if not for CICS or IMS)
Terminal identifier (omitted if not for CICS)
User/operator identifier (omitted if not for CICS)
Actual Program Name - contains the executable application name.
Jobid (z/OS Job ID)
A format identifier that can be used to parse the previous positional information. If the
information ends with the four characters ' LSS' (note the leading blank), then the format
identifier value is present. The first two characters of the format identifier indicate the
number of values present before any Actual Program Name (currently either 07 or 11).
The next two characters indicate the version of format identifier. If 01, the Jobid value is
present; if 02, the Actual Program Name and Jobid values are present.
The format identifier, while cryptic, allows new information to be added after what were
originally trailing optional values. If the format identifier is not present, then Jobid is not
present, and only the first seven or eleven fields will be present.
Older versions of TDP provided only one eight-character field, which contained the
jobname (z/OS jobname).
Self-Defining Variable-Length Items

Zero or more variable-length EBCDIC items can be present, enveloped by a descriptive name
and enclosed in parenthesis, each separated by a comma.
32
TDP() provides the TDP release identifier
CL2() provides the CLIv2 release identifier
SESSDESC() provides information specified by the application using the CLIv2 Sessiondesc specification. This is purely descriptive information, otherwise unused.

Sessions
WORKLOAD() provides information specified by the application using the CLIv2

Workload specification. This is information formatted as defined, and intended for use, by
the Database.
If the length of the self-Defining items results in Logon Source Information larger than the
size of the DBC.SessionTbl LogonSource column, TDP will truncate them as necessary,
indicating such a truncation by the string '...)', if room permits.
Diagnostic Status and Detail

In diagnostic situations, messages can be requested whenever a session is logged on or off
using the TDP ENABLE SESSION STATUS and ENABLE SESSION DETAIL commands. It is
not recommended during normal operations if the rate of session activity is large because of
potential adverse impact on system console processing. The TDP DISABLE SESSION STATUS
and DISABLE SESSION DETAIL commands reverse the ENABLE commands. When
SESSION STATUS is enabled, a TDP0899 message indicates when a session starts, and a
TDP0898 message indicates when a session ends. When SESSION DETAIL is enabled, when a
session ends, a TDP0846 message indicates the total elapsed time that the session spent within
the application and within the Teradata Database.
Session Pools
When many similar sessions are logged on to perform some quick activity then logged off, the
time to establish the session can be much longer than the time to perform the activity. In such
cases, session pools can be established. Sessions for a pool are logged on once and re-used for
subsequent logons, thus eliminating the overhead of subsequent logons. Session pools are
established using the TDP START POOL command. In diagnostic situations, messages can be
requested whenever a pool session is assigned or released using the TDP ENABLE POOL
STATUS command. It is not recommended during normal operations if the rate of session
pool activity is large because of potential adverse impact on system console processing. The
TDP DISABLE POOL STATUS command reverses the ENABLE command. When POOL
STATUS is enabled, a TDP0802 message indicates when a pool session is assigned, and a
TDP0803 message indicates when a pool session is released. It can occasionally be difficult to
understand why a session pool session is not assigned, so in such diagnostic situations the
TDP ENABLE POOL DETAIL command can be used to produce TDP3100 through TDP3105
messages, which describe the reason a logon was not eligible to use a pool session, or TDP3120
through TDP3127 messages, which describe why a pool session could not be assigned.
Automatic logoff
When an application ends without logging off its Teradata session, they are automatically
logged off. This also occurs in z/OS or VOS3 when the task or address space terminate.
In-Doubt Session Resolution

For sessions using two-phase commit, if a coordinator fails the Teradata Database cannot
unilaterally decide to commit or roll back the updates. When either the coordinator returns or
manual resolution of the in-doubt session becomes necessary, TDP provides facilities to
33

Requests
inform the Database of the resolution. The TDP AUTHORIZ command is used to allow a
coordinator to use the TDP RESOLVE command.
The TDP COMMIT and ROLLBACK commands can be used to perform manual in-doubt
resolution. Manual resolution can also be performed from the Teradata Database using the
TPCCONS utility on the RDBMS console. For details see Utilities.
Warning:
Manual resolution of in-doubt sessions must be done with care. Incorrect manual in-doubt
resolution causes a loss of data integrity between the participating databases.
Replication
The Teradata Database supports a capability known as replication by which Database data is
mirrored on another database. In effect, the two-phase commit protocol is used internally to
ensure the two databases remain synchronized. This use of the protocol is not made visible to
TDP. As a result, unbounded delays can occur at various points which will simply appear as
hangs. For example, under at least the following circumstances delays unattributed delays will
occur if replication is involved in in-doubt resolution:
When TDP is started
When a session logs off
Requests
Requests are initiated by applications to perform work on the Teradata Database. The
following aspects of requests are presented:
Effect of a Database Restart
Preventing Application Time-out
Flow through TDP
Effect of a Database Restart

When the Database restarts, sessions remain but active requests not in-doubt are terminated.
When the Database recovers, TDP elicits error responses from the Database for all requests
that were active at the time of the restart. These responses will then be reflected to the
application.
Sessions that did not have active requests but were in-transaction have lost the in-transaction
state. So the next request sent by the application will be unconditionally aborted to reflect the
loss of transaction status to the application.
In-doubts requests remain in-doubt.
If a previously active SP is down after a restart, TDP will switch any sessions on that SP to
other SPs as session capacity exists. This is transparent to the application except that a request
initiated before the session is switched will be delayed.
34

Requests
Preventing Application Time-out

z/OS provides for abnormal termination of jobs or virtual machines that have been in a
continuous WAIT state for an installation-specified time interval (on z/OS this interval is
specified using the SMF Job Wait Time (SMFJWT) value). However, a Database response can
sometimes need to wait longer than this (for example, when the job is issuing lengthy or very
complex Teradata SQL requests). To prevent a z/OS system 522 abnormal termination of such
a job. TDP at the option of the installation wakes the job or virtual machine. The
installation can use the TDP INITIAL JOBWAIT command to specify a value less than the
installation-specified value for z/OS's SMFJWT.
Flow through TDP

When the application initiates a request, if TDP can accept the request it is received into the
TDP address space or virtual machine. Requests will not be accepted if the specified TDP is
not started, the TDP RUN command has not been issued, communication is not established
with the Teradata Database, there is a TDP resources shortage (such as virtual storage), or
TDP is being shutdown. The TDP DISPLAY TDP command will indicate if the RUN
command has not been issued or TDP is shutting down.
Once accepted, any system security or exit processing is honored then a CP is selected to send
the request to the Database and the request added to that CPs queue. When at the top of the
queue, it, possibly packed with other requests, is sent to the Teradata Database and TDP awaits
a response on the same CP. Meanwhile TDP process other requests queued for that or other
CPs. The TDP DISPLAY TDP command will indicate if the SECLOGON is enabled or the
Security, Logon, or Monitor exits are enabled.
When a response to the request is completely received from the Database, any exit processing
is performed, and the request is returned to the application and the application is notified.
The TDP DISPLAY TDP command will indicate if the Monitor exit is enabled.
While a request is known to TDP, various TDP commands can be used to ascertain its status.
A TDP DISPLAY JOB command can be used to list the Teradata session numbers associated
with a z/OS or VOS3 job. It will also indicate whether or not each session has a request active
in TDP. The TDP DISPLAY SESSIONS command can be used to obtain information about
particular Teradata sessions. If the If the DETAIL operand is specified, more detailed
information is presented about the active request, or if none is active, about the last request.
For an active request, the first character of the INFO code indicates where in the flow through
TDP the request is:
0x if there is no active request
8x if a request has been accepted by TDP
Cx if a request is queued for a CP
Ax if a response is expected from the Database
9x if a response has been received from the Database
The total time the session has existed and the elapsed time for the active (or last) request can
also be useful. Also significant is a three-part ratio giving the proportion of total session time
spent within TDP, within the Database, and within the application.
35

TDP Virtual Storage
The TDP DISPLAY CP REQUESTS command lists the requests queued for, and the requests
sent on, a CP.
TDP Virtual Storage

Virtual storage within the TDP address space or virtual machine is almost entirely in direct
support of customer requirements, which fall into one of two areas:
Handling requests and responses
Communicating with the Database
Handling Requests and Responses

To receive a request from an application, that request must be copied from the application to
TDP, so requires TDP virtual storage until sent to the Database. To receive a request's response
from the Database, that response must be copied from I/O buffers to TDP virtual storage until
returned to the application. Each request and response consists of three pieces: a piece
representing work within TDP, a piece representing the request within TDP, and a piece
containing the actual request or response data. Every request or response consists of one
storage area for each of the first two pieces plus one or more storage areas for the third piece,
depending on the size of the data.
All these areas are satisfied from TDP storage cells. Cells are allocated in different sizes to
handle different uses. The first piece requires one 256-byte cell, the second one 416-byte cell,
the third one or more 992-byte cells.
While the sizes are determined by TDP and cannot be changed, the number of cells for each
size are controlled by the customer to balance the work required of TDP against the amount of
virtual storage used. If there are insufficient cells, that processing waits until the needed cells
are freed by other processing. If there is little other work or not enough cells were configured,
that processing can never complete.
The TDP ADD CELLS command is used to add cells of specified sizes; the TDP DISPLAY
CELLS command is used to obtain the status of the cells. There is no way to remove cells once
added except to restart TDP.
Communicating with the Database

To communicate with the Database using CCU-type CPs, storage is automatically managed by
TDP to balance CP performance with storage utilization. The amount of storage used varies
with demand, storage being obtained, re-used, or freed according to internal algorithms, with
all such storage available to any CCU-type CP. The minimum and maximum amounts of
storage that can be used varies with the number of such CPs that are STARTed and the
INITIAL IACMODE. The type of storage depends upon the INITIAL IACMODE
specification, based on underlying operating system limitations. 31bit storage fixed in real
storage is used if the IACMODE is EXCPVR, IOSDRIVR, or DIAG98. Unlike the TDP cells, no
configuration or tuning is required. However, the maximum can be limited by using fewer
CPs or IACMODE EXCP.
36
CHAPTER 3
Performance Measurement
To evaluate Teradata Database performance, you can use the optional Host System Interface
(HSI) time stamps.
When you use this option, the Host System Interface to TDP (HSIT) forwards time stamps
from various parts of the client system.
The information is returned in the CLIv2 DBCAREA. For details on DBCAREA, see Teradata
Call-Level Interface Version 2 Reference for Mainframe-Attached Systems.
DBCTSTMP
DBCTSTMP contains the time-of-day clock time that is stored when a request is actually
started by the HSIT. This time differs slightly from the time the HSIT is actually issued
because of initialization processing.
General Tuning Options

Introduction
All client software can be tuned using options provided by TDP and the Teradata Database.
TDP Options
To provide for memory acquisition during system operation without incurring the high
overhead associated with the GETMAIN/FREEMAIN memory services, TDP acquires units of
main memory, or cells, from its own, more efficient memory manager.
During startup, the memory manager pre-allocates a number of cells in sizes that are
convenient for use by TDP. The sizes of the cells are internal constants. The initial number of
cells is an internal default.
37
Chapter 3: Performance Measurement

WHEN a . . .
THEN the . . .
TDP subtask requests a cell from the memory

manager, but all available cells are being used by
other TDP subtasks
memory manager does one of the following:
requester is placed into a wait
wait ends when another TDP subtask releases a

cell.
Obtains a single cell using a GETMAIN call

to the operating system
Places the requesting subtask into a wait for
memory
The decision to use GETMAIN or wait is based

on the cell size and the identity of the requesting
subtask.
Monitoring Performance and TDP Cells

A system programmer can use the TDP DISPLAY CELLS command to monitor the
performance of the TDP cell system. TDP will display the following cell system statistics in
response to the DISPLAY CELLS command:
Size of cells in use
Number of each size of cell allocated to TDP
Number of each size of cell currently in use
Maximum number of each size of cell used at any one time
Number of times GETMAIN was used to satisfy requests because all cells allocated were in
use
Number of cross memory cells initially in use
Number of times that a TDP subtask was placed into a wait because all cells of that size
were in use
You can view final statistics in the following records:
In z/OS, the SMF shutdown record
In VOS3, the SMS record
If this information indicates that the number of cells currently allocated is not adequate for
certain kinds of processing, more cells can be provided to the memory manager. Cells can be
added during TDP startup via the ADD CELLS operator command, which can be executed
from the TDPPARM data set, or from the system console.
For example, if the statistics indicate problems in any client performance for FastLoad
operations, a systems programmer can decide to add cells of data buffer size before running
the next FastLoad.
38

Tuning TDP Cells to Optimize Performance

Follow the tips in the following table to ensure that your TDP cells are tuned for optimum
performance.
Question
Answer
How do I know whether to

add regular cells or PC cells
when I experience a cell
shortage?
If a normal cell pool is exhausted, a TDP0021 message is issued. If an

XMS cell pool is exhausted, either a TDP0201 or TDP0202 message is
issued.
When can I use the ADD

CELLS command?
You can use the ADD CELLS command in the following

circumstances:
The response to a DISPLAY CELLS command will also indicate cell

exhaustion. For a normal cell pool, a TDP0528 message indicates the
number of exhaustions. For an XMS cell pool, the TDP1520 and the
TDP1521 messages indicate exhaustions.
While TDP is running

As a TDPPARM dataset parameter
You cannot use ADD CELLS as a TDPPARM dataset parameter if you
want to add 12,272 byte cells; instead, you should use INITIAL
IOBUFS.
When can I subtract cells?
You cannot subtract cells.

Whenever you start TDP, cell allocations return to the TDP defaults
unless the TDPPARM dataset parameters have one of the following
commands:
ADD CELL
ADD XMSCELL
INITIAL IOBUFS
How do I change the

number of Input/Output
buffers?
Use the INITIAL IOBUFS command to specify the number of Input/

Output data buffers.
What is the default number

of cells used for Input/
Output?
6 per CP.
Note: IOBUFS are not used for CPs requiring the CCU operand on
the START command. These CPs automatically manage their I/O
buffers.
This is true both for 480 byte and 12,272 byte cells.
More highly stressed CPs should be allocated more cells.
To do this, use either ADD CELLS (while TDP is running) or
INITIAL IOBUFS (in the TDPPARM dataset).
Note: IOBUF cells (12,292 byte cells) are not used for CPs requiring
the CCU operand on the START command. Exclude these CPs when
considering the default cell size.
39

Question
Answer
What are the most

important cell sizes and
what are they used for?
There are four common cell sizes. The 480 and 12,272 byte sizes (also
known together as I/O buffers or IOBUFS) are both needed for I/O.
Common uses are explained in the following table.
Cell size (bytes)
Usage
240
1 cell is required per session.

1 cell is required per interface processor.
992
Request and response buffers
480
Move requests and responses across the

channel between the client and the
Teradata Database.
12,272
For CPs started without the CCU

operand on the START command, move
requests and responses across the
channel between the client and the
Teradata Database.
Scenario
Suppose a customer has been getting TDP0021 warnings for 992 byte cells (data buffers), for
example:
TDP0021 **WARNING** 100% OF 992 BYTE CELLS IN USE
The maximum number of data buffers required is equal to the product of the number of
sessions and the amount of data transferred divided by 992:
((number of sessions)(amount of data transferred))/992
The amount of data transferred applies to both requests and responses.

For all but the most unusual cases, you should not need this maximum number of data
buffers. Cell usage can push the maximum in cases where the ratio of interface processors to
AMPs on the system is very low (for example, 8:104). In this case, data transfer through the
interface processor is a bottleneck because each session sends a request into TDP, and those
requests become enqueued within TDP because the bottleneck restricts TDPs ability to
dispatch the requests to the Teradata Database in a timely way.
This creates a producer-consumer relationship in which the sessions produce requests (up
to 32K each in the case of FastLoad) that are buffered in TDP until the Teradata Database can
consume them. The interface processor bottleneck represents slow consumption, and more
data ends up buffered in TDP than would normally occur.
More commonly, the sessions communicating through TDP might, at any given instant, be in
one of several states. These states include:
40

Request inside TDP waiting for I/O to the Teradata Database

(Requires TDP cells)
Request active on the Teradata Database (Does not require cells)
Response received in TDP but not yet sent to the application

(Requires cells)
Response sent to the application, but next request has not yet arrived (Does not require
cells)
At any given moment, the number of sessions whose request is within TDP but has not yet
been sent to the Teradata Database is less than or equal to the total number of sessions logged
on. You should set the number of cells above the average, but below the peak. Average and
peak are functions of the configuration and the workload. For example, running five FastLoad
jobs and several BulkLoad jobs on a Teradata Database with eight interface processors and 104
AMPs produces a much higher average percent of sessions with requests/responses passing
through TDP than would a sixteen interface processor, 104 AMP Teradata Database.
The optimal way to handle standard use is to set the number of cells just above the average and
then let TDP memory management algorithm deal with peak activity periods because it is
generally neither practical nor beneficial to give TDP the number of cells required to handle
peak requests. Generally, it is better to let requests back up in the application address space
instead. Such an approach should provide equal or better throughput while at the same time
ensure better usage of CPU and real storage consumption by the operating system.
The message noted at the beginning of this section, the TDP0021 message, indicates the
percentage of available cells that are in use. Peaks of 100% are not cause for alarm, though an
average of 100% indicates that you should add more cells. In general, assume that somewhere
between 20 and 30 percent of the sessions active are inside TDP at any given moment.
Example of How to Analyze Cell Usage Optimization

For the purpose of this example, assume the following things:
A system with 8 CPs, 8 SPs and 100 AMPs
5 FastLoads running using 100 sessions
5 BulkLoads running using 100 sessions
Each FastLoad or BulkLoad request is 32K (this produces approximately 33 992 byte cells,
for a total of 31 Mbytes)
System is running with the default initial cell values, resulting in a TDP0021 message
indicating exhaustion of 992 byte cells and/or a TDP0202 message indicating exhaustion
of XMS cells.
10% of the sessions have requests in transit through TDP simultaneously at any given
moment.
Observations
The theoretical maximum of cells is (number of jobs) (sessions per job) (number of cells), or
(10)(100)(33) = 33,000 992-byte cells.
41

z/OS and VOS3 Performance Measurement
Given the assumptions, there should be about 3300 cells (.10)(33,000) = 3300.
Procedure
Follow this procedure to optimize cell usage.
1
Issue an ADD CELLS command to bring the 992 byte cells up to a total of 3300.
Run the workload again (5 FastLoads and 5 BulkLoads).
Issue a D CELLS command at regular intervals to determine the number of available and
in use cells.
Use the results of the D CELLS query as follows.

IF . . .
THEN . . .
the system is still at 100% utilization
add more cells.
cells are always available
reduce the number of cells.
Remember to aim for slightly more than average, not for the peak.
System Options
System performance is affected by the load on the block multiplexer channel, which is
connected to the Teradata Database.
For the best system performance, a channel that is used by the Teradata Database should be
dedicated to devices to that Teradata Database. However, if research at your site indicates that
a channel is not overloaded, you can share that block multiplexer channel with other devices,
such as disk or tape devices.
It is the responsibility of your site to monitor channel utilization to determine if it is high
enough to degrade the performance on the Teradata Database. Note that an overloaded
channel will result in I/O delays for other devices on that channel.
z/OS and VOS3 Performance Measurement

Introduction
In addition to HSI time stamps described previously, z/OS and VOS3 client software generate
records to provide performance data, as follows:
In z/OS, SMF records
In VOS3, SMS records
The contents of the records are described by the TDPSMFR macro, which is distributed with
the product.
42

CP Shutdown Record
SMF/SMS Records
SMF/SMS is a standardized mechanism that provides accounting and performance
information. As an option, the TDP subsystem generates an installation-specified SMF/SMS
record type. The SMF/SMS record ID is the record number where TDP accounting and
performance data is recorded. The record ID is specified in the Host System Interface System
Parameter Block (HSISPB). The HSISPB is delivered with a default ID. The SMF/SMS record
type can be one of the following subtypes:
SMF Record Subtype
Description
CP shutdown
Statistical information about the processing activity of a CP, recorded at

shutdown.
Logoff
General information about a session being logged off and details about
the sessions use of z/OS or VOS3 client and Teradata Database
resources.
Logon violations and

security violations
Logon violations information provided by the User Logon Exit Interface

and security violations information reported by the Teradata Database.
TDP shutdown
Statistical information about the processing activity of TDP, recorded at

shutdown.
Structure-protocol
termination
Information about the communication protocol for a CP started with

the CCU operand.
All the SMF/SMS record subtypes are described in further detail in the following sections.
CP Shutdown Record
Introduction
Shutdown of a CP generates SMF statistical records about the normal processing capability of
that CP.
Usage Notes
Shutdown information can be used to determine optimum table sizes and numbers of cells
(units of main memory) to be implemented through the TDPPARM data set.
Record Contents
The shutdown record for a CP contains the following information:
Channel Processor number
Total number of messages, blocks and bytes sent and received
CP start and stop times
43

Logoff Record
Logoff Record
Introduction
During the logoff process, normal or abnormal, the TDPSESS module (the general session
control interface) generates an SMF record. This record contains general information about
the session being logged off, as well as details about the overall use of z/OS or VOS3 client and
Teradata Database resources.
Record Contents
The logoff record includes the following information:
Session start and end times
Session number, session processor number
Teradata Database logoff completion code
Session termination status (why the session ended, for example, because of command, end
of task, user request)
Session idle time (time spent waiting for applications to issue requests, in .01-second
units)
Session busy time (time spent waiting for the Teradata Database to complete requests, in
.01-second units)
TCB, job name, job start time
Total number of start, continue, and other requests
Thousands of bytes sent and received
All times are recorded in SMF/SMS date/time format:
Date: in packed decimal cyydds
Time: in 0.01-second units
Security Violations Record

Definition
An SMF record of security violations reported by the Teradata Database or logon violations
reported by the User Logon Exit Interface (TDPLGUX) is optionally written to the SMF data
set.
Usage Notes
This information can be correlated with the logoff record to identify users who are violating
installation standards and security procedures. To simplify correlating these records with
other job- and step-related records, security records contain the standard SMF job
identification: job name, step number, and date/time the reader recognized the job card.
44

TDP Shutdown Record
For details about the User Security Interface (TDPUSEC) and the User Logon Exit Interface
(TDPLGUX), refer to Chapter 4: Customer Exits and Teradata Userid Authentication.
Record Contents
The security violations record contains the following information:
Job name and TCB of the violator
Type of violation: logon or Teradata Database security violation
Session and request number
Session processor used
Type of request causing the violation
Action taken by the user security exit (TDPUSEC)
TDP Shutdown Record

Introduction
Shutdown of TDP generates SMF statistical records about the normal processing capability of
TDP.
Usage Notes
As with CP shutdown information, TDP shutdown information also can be used to determine
table sizes and numbers of cells to be implemented through the TDPPARM data set.
Record Contents
The shutdown record for a TDP contains the following information:
Total time TDP was active
Size of session control tables
Size and number of cells
Number of times the GETMAIN or FREEMAIN memory services of z/OS or VOS3 were
invoked to obtain needed cells
Structure-protocol Termination Record

Introduction
Termination of a CP that was started with the CCU operand records information about the
communication protocol. Since the information is normally most useful to Teradata customer
support people, this record is disabled by default and is not further documented here.
45

z/OS and VOS3 Tuning With the HSI System Parameter Block
Usage Notes
Since the protocol is terminated when the CP is shut down, every record of this type will be
followed by a CP Shutdown Record. However, since the protocol is re-initialized after each
Teradata Database restart, there can be more records of this type than CP Shutdown records.
z/OS and VOS3 Tuning With the HSI System

Parameter Block
Introduction
You can change the size and number of TDP memory cells in the HSI System Parameter Block
(HSISPB) to control the timing and performance of the HSI/TDP interfaces.
Size, Number of TDP Memory Cells

If use of the DISPLAY CELLS command indicates that the GETMAIN memory service has
been used too many times to satisfy TDP requests for main memory, the ADD CELLS
command can be used to improve TDP performance by adding cells of a specified size to main
memory.
z/OS Tuning With I/O Mode Options

Introduction
System performance can be affected by the EXCPVR or IOSDRIVR options of the INITIAL
IOMODE command (described in Chapter 7: TDP Commands). The INITIAL IOMODE
command sets the input and output mode that TDP uses for communicating with the
Teradata Database.
TDP performance can be constrained by the EXCP option since it limits I/O buffers to 24 bit
storage, so fewer buffers are likely available for transferring data between TDP and the
Teradata Database.
EXCPVR Option
You can use the EXCPVR option instead of the default EXCP option to eliminate any address
translation of channel programs by the z/OS I/O supervisor (IOS) each time the channel
program supervisor call is invoked.
With EXCPVR, the data areas involved in the I/O operation and the area containing the
channel program are page-fixed. Therefore, address translation for the Channel Control
Words (CCWs) that make up the channel programs is done only once, during TDP
initialization.
46

IOSDRIVR Option
In the z/OS environment, the IOSDRIVR option can be used instead of EXCP or EXCPVR.
The IOSDRIVR option directs the z/OS TDP to call IOS directly through the STARTIO macro
interface to request that I/O be done on its behalf. To make TDP invoke the IOS driver routine
(TDPIODVR) instead of invoking EXCP or EXCPVR, In the TDPPARM data set, include the
TDP INITIAL command:
INITIAL IOMODE IOSDRIVR
In a heavily loaded TDP, the IOSDRIVR option can reduce CPU utilization when compared to
EXCP or EXCPVR. Also, where TDP I/O queue lengths are consistently greater than 0, the I/O
path lengths can be reduced because the disabled interrupt exit (DIE) will fetch the next I/O
request and submit it to IOS. Whenever the I/O completes successfully, post status processing
(back-end IOS) also is avoided.
Since the TDP address space is nonswappable, and the I/O related control blocks are in fixed
storage, Teradata Database-bound I/O will be re-driven out of any address space. That is, this
occurs wherever the I/O interrupt is fielded for the previous I/O, thus avoiding address-space
swapping to handle the interrupt and subsequent re-drive of new I/O.
47

48
CHAPTER 4
Customer Exits and Teradata Userid

Authentication
At four points TDP will call exit routines if they are provided by the customer:
1
Any User Address Space exit (TDPUAX) receives control in the application address space
when a Teradata session is being established.
Any User Logon Exit (TDPLGUX) receives control in the TDP address space when a
Teradata session is being established.
Any User Transaction Collection Exit (TDPUTCE) receives control in the TDP address
space before requests are sent to, or after responses are received from, the Teradata
Database.
Any User Security Interface (TDPUSEC) receives control in the TDP address space when
the Teradata Database has detected a security violation.
User Address Space Exit

Introduction
The User Address Space Exit (TDPUAX) is available only in the z/OS or VOS3 environment.
It is called in the address space of the application when an application initiates a request to the
Teradata Database.
The exit can accept, reject, validate, or modify the logon string of the caller.
The exit can be activated using the TDP ENABLE UAX command, either as part of TDP
startup in TDPPARM, or anytime thereafter. It can be deactivated anytime using the TDP
DISABLE UAX command.
If the TDPUAX module is replaced, the new version can be used by first deactivating the old
version using the TDP DISABLE UAX command then activating the new version using the
TDP ENABLE UAX command. Between the two commands, TDPUAX is not being used.
TDPUAX Operation
TDP builds and passes a parameter list to TDPUAX. The parameter list consists of the
following:
TDP information
Requestor information
49
Chapter 4: Customer Exits and Teradata Userid Authentication

Parameter data
Logon information
When TDPUAX is called during an application logon or connect request, it can be used to:
Accept the logon request and return to TDP with a return code of zero. This causes TDP to
send the logon string to the Teradata Database and return to the application with an initial
status return code of zero.
Reject the logon request by sending a nonzero return code to TDP. TDP immediately
returns to the application with a non-zero return code.
Modify the logon request in the TDPUAX build area and notify TDP that the logon string
has been modified.
Set a flag when it returns, indicating that the logon string has been validated. This causes
TDP to notify the Teradata Database that the exit has validated the logon.
In a validated logon, the password field of the logon string is optional, and is ignored if
present. The userid must be a valid userid with the proper rights granted, as described
above. An account string, if it is used, must be valid and will be respected.
When TDP has authenticated the Database userid, the Database requires that both the logical
host on which TDP resides and the Teradata Database userid both have been granted the right
to logon with null password.This is accomplished for a particular userid by the SQL GRANT
LOGON ON <logical host id> TO USERID <userid> WITH NULL PASSWORD or for all
userids by the SQL GRANT LOGON ON <logical host id> AS DEFAULT WITH NULL
PASSWORD.
While Database userids must be defined with a password, the password is ignored when TDP
has authenticated the Database userid. Since it is ignored, an expired password will not
prevent a logon when TDP has authenticated the Database userid, though it will prevent a
logon when TDP has not authenticated that userid, since the password is used.
This exit does not currently support a terminate call, therefore any cleanup after the
application ends or abend must be managed by the application.
For an example of coding TDPUAX, refer to the sample TDPUAX that is shipped with TDP.
Customizing TDPUAX
When customizing a TDPUAX module, the following points must be considered:
50
As with any system exit, TDPUAX must be carefully coded and debugged with the
assistance of an experienced system programmer. Any errors in TDPUAX can damage the
application address space or the operating system itself.
TDPUAX obtains control in supervisor state, key 7, enabled, in home mode, in task mode,
with the local lock held. Since TDPUAX is locally locked, no SVCs can be issued. The local
lock must not be released.
If you are using MVS/XA or above, TDPUAX must specify AMODE 31 (in VOS3, specify
TRAIT EA) because the data buffers may reside in virtual storage greater than 16 MB.
During its execution, the TDPUAX can change the addressing mode, but it must later

return control in the addressing mode of the caller (as indicated on entry by bit 0 in
general register 14). This is normally accomplished using the instruction, BSM 0,14.
A single copy of TDPUAX resides in CSA and is shared by all address spaces in the system.
Therefore, it must be coded and linked re-entrant.
Any memory obtained by TDPUAX should be associated with the jobstep task for the
following reasons:
It enables the Teradata Database to distinguish between calls from different

applications.
TDPUAX can include a user word in its parameter list to maintain context across calls.
The parameter list is associated with the jobstep task under which the application is
executing. Thus, the contents of the user word are passed to TDPUAX with each call
under that jobstep task.
If another application is executing under a different jobstep task in the same address
space and initiates a logon to the Teradata Database, a different parameter list (and
thus another unique user word) is passed.
It ensures that the operating system cleans up the memory when the jobstep task
terminates, since there is no termination call to TDPUAX.
The interface to TDPUAX is established through standard OS linkage conventions. Upon

entry, TDPUAX is passed the address of an 18-fullword save area in register 13. TDPUAX
must save the callers registers on entry and restore them before returning to the return
address that is passed in general register 14.
If TDPUAX invokes services that require a save area, TDPUAX must provide one for the
use of that service.
Control is passed to TDPUAX with general register 1 pointing to the TDPUAXP control block
(parameter list), which contains the following:
A user word that can be set by the exit and remain intact on subsequent calls (under the
same jobstep TCB)
TDP information
Parameter information
Logon information
Note: The TDP identifier and separating slash that CLI allows as a prefix to the Logon
String, and the ending semicolon character, are removed by CLI, so are not present within
the exit.
Session character set information
If the logon string is parsed, the userid, password, and account name each consists of
characters from the session character set. When supported by the session character set, each
contiguous group of double byte characters is preceded by the Shift-out control character,
X0E, and followed by the Shift-in control character, X0F. Neither commas nor blanks can be
specified as double byte characters.
On return, TDPUAX passes one of the following return codes to TDP in general register 15:
51

User Logon Exit Interface
Return
Code
Meaning
Allow the logon request to continue.
Nonzero
Do not allow the logon request to continue.
The parameter list is described by the TDPUAXP macro, which is distributed with the
product.
Installing a Customized TDPUAX

You can install a customized TDPUAX during normal TDP operation in the z/OS or VOS3
environment. Follow these steps to install a customized TDPUAX:
1
Rename the current version of TDPUAX. (This allows you to revert to the previous
version, if necessary.)
Compile and link-edit the customized TDPUAX module into the <dbcpfx>.TDPLOAD
library, specifying link-edit options that are consistent with the guidelines listed above.
Install the customized TDPUAX with SMP (z/OS clients only) as a USERMOD to prevent
overlaying a customized TDPUAX with a replacement TDPUAX module supplied in a
later software release.

Introduction
Through the User Logon Exit (TDPLGUX), a user-provided routine can reject, accept,
provide, or modify a logon request. The exit also allows the user to send the following options:
No logon string (TDP has authenticated the Database userid)
Only a user id that the user routine provides a password for
A user id that can be validated as not requiring a password
The exit can be activated using the TDP ENABLE LGUX command, either as part of TDP
DISABLE LGUX command.
If the TDPLGUX module is replaced, the new version can be used by first deactivating the old
version using the TDP DISABLE LGUX command then activating the new version using the
TDP ENABLE LGUX command. Between the two commands, TDPLGUX is not being used.
TDPLGUX Operation
TDPGLUX processes three types of calls:
52
Initialization

Logon requests
Terminate
The exit is initialized when an ENABLE LGUX command is executed. During initialization,
TDPLGUX obtains a work area, opens files, and so on.
A logon request is passed to the TDPLGUX before the request is allowed to continue.
When a logon request call is made to TDPLGUX, it is processed in the following manner.
1
TDP builds and passes a parameter list to TDPLGUX. This parameter list consists of:
TDP information
Time stamps
Timing precision
Parameter data from TDPUAX (User Address Space Exit) (z/OS or VOS3 only)
Logon information
Modify the default SECLOGON class.
The TDP identifier and separating slash that CLI allows as a prefix to the Logon String,
and the ending semicolon character, are removed by CLI, so are not present within the
exit.
2
After the user routine processes the parameter data, the exit can:
Reject or accept the logon string.
Validate the logon string (if it contains only a user id).
If TDP has authenticated the Database userid, provide a logon string.
Determine if the logon string has already been validated by TDPUAX (z/OS or VOS3
only).
Modify the logon string. If the logon string is to be modified, the exit is passed the
location and length of the logon string in the parameter list.)
When TDP has authenticated the Database userid, the Database requires that both the
logical host on which TDP resides and the Teradata Database userid both have been
granted the right to logon with null password. This is accomplished for a particular
userid by the SQL GRANT LOGON ON <logical host id> TO USERID <userid> WITH
NULL PASSWORD or for all userids by the SQL GRANT LOGON ON <logical host id>
AS DEFAULT WITH NULL PASSWORD.
While Database userids must be defined with a password, the password is ignored when
TDP has authenticated the Database userid. Since it is ignored, an expired password will
not prevent a logon when TDP has authenticated the Database userid, though it will
prevent a logon when TDP has not authenticated that userid, since the password is used.
3
If the logon request is accepted, TDPLGUX sends a return code of zero.

If the logon request is rejected, TDPLGUX sends a nonzero return code and the violation
is reported to the security exit.
53

For an example of coding TDPLGUX, refer to the sample TDPLGUX that is shipped with
TDP.
The parameter list is described by the TDPLGPRM macro, which is distributed with the
product.
Customizing TDPLGUX
When customizing a TDPLGUX module, the following points must be considered:
Because TDPLGUX runs as part of TDP, it is privileged. If improperly coded, it can cause
errors or even destroy TDP.
TDPLGUX can access only data supplied by TDP in data control blocks described in
MACLIB and SAMPLIB, on a release tape of Teradata software. It can not access other
TDP components.
TDPLGUX can directly use most normal OS services.
If TDPLGUX is abnormally terminated, TDP error recovery disables TDPLGUX and

allows logon requests to continue, but once the problem is resolved it can be reactivated
using the TDP ENABLE LGUX command.
On z/OS or VOS3, a dump is written to theTDPSNAP DDName. If the exit attaches tasks
and a subtask abnormally terminates, TDP does not process the error. That is, the exit is
not disabled and no dump is written by TDP. However, the operating system may record
the dump if the standard resources are available (a SYSUDUMP DD statement on z/OS,
for example). It is the exits responsibility to properly manage its subtasks so that such
failures do not impact its operation.
TDPLGUX runs under TDP as a single-threaded routine, and can process only one request
at a time. Consequently, the exit routine must be at least serially reusable or re-enterable in
order to be compatible with the rest of TDP.
TDPLGUX can keep its own tables. A single word is always passed between TDPLGUX
and TDP as part of the parameter list. TDPLGUX can use this word to point to a block of
storage containing information that is required across calls.
As a subroutine of TDP, TDPLGUX must save and restore registers in the standard OS
format when it is called. If other services besides TDPLGUX also are called, the routine
must provide its own save area. Finally, TDPLGUX must return to the address passed in
general register 14.
Control is passed to TDPLGUX with general register 1 pointing to the TDPLGPRM control
block. This control block contains a user word, the logon string, pointers to fields containing
information about the register, and the session character set.
If the logon string is parsed, the userid, password, and account name each consists of
characters from the session character set. When supported by the session character set, each
contiguous group of EBCDIC double-byte characters is preceded by the Shift-out control
character, X0E, and followed by the Shift-in control character, X0F. Neither commas nor
blanks can be specified as double byte characters.
On return, TDPLGUX passes one of the following return codes to TDP in general register 15:
54

TDP User Transaction Collection Exit
Return Code
Meaning
Allow the logon request to continue.
Nonzero
Do not allow the logon request to continue.
Installing a Customized TDPLGUX

You can install a customized TDPLGUX during normal TDP operation. Follow these steps to
install a customized TDPLGUX:
1
Rename the current version of TDPLGUX (either as originally supplied by Teradata or as

modified by your site) to allow you to revert back to the previous copy if necessary.
Compile and link-edit the customized TDPLGUX module into one of the following:
In z/OS and VOS3, the <dbcpfx>.TDPLOAD
In the z/OS or VOS3 environment, install the customized TDPLGUX with SMP as a
USERMOD to prevent overlaying a customized TDPLGUX with a replacement TDPLGUX
module supplied in a later software release.

Introduction
TDP User Transaction Collection Exit (TDPUTCE) is a routine that allows the user to collect
statistics about all of the requests and responses that traverse TDP.
The exit can be activated using the TDP ENABLE TMON command, either as part of TDP
DISABLE TMON command.
If the TDPUTCE module is replaced, the new version can be used by first deactivating the old
version using the TDP DISABLE TMON command then activating the new version using the
TDP ENABLE TMON command. Between the two commands, TDPUTCE is not being used.
TDPUTCE Operation
TDPUTCE processes four types of calls:
Initialize
Request
Response
Terminate
The exit is initialized when an ENABLE TMON command is executed. During initialization,
TDPUTCE performs activities such as obtaining a work area and opening files.
55

Parameters Passed
When a request or a response call is made, the exit is passed parameters containing the
following information:
Input parameters to the TDPUTCE
TDP information
Session or request information
Time stamps
Timing precision
Function code (request type)

Refer Table 3-1 to below.
Request or response data
Enlarged parcel usage support
Character set information
A terminate call is sent to the exit at TDP termination time or when a DISABLE TMON
command is executed.
When the TDPUTCE is enabled, TDP calls the user data collection routine via a BALR 14,15,
with register R1 pointing to the parameter list. The parameter list is described by the
TDPMNPRM macro, which is distributed with the product.
Table 1: Function Codes Descriptions
Function
Code
Function Name
Origin
Buffer content for

Request call Type
Buffer content for

Response call Type
Logon request
CLIv2 Connect
function
Request parcels
Response parcels
Logoff request
CLIv2 Disconnect
function
CLIv2 Cleanup
routine
CLI CICS DLGF

transaction
IMS transaction
termination
56
Run request
CLIv2 Connect
function
Request parcels
Response parcels
Logoff All
Application
termination
(none)
(not called)
Logoff All Task
Task termination
(none)
(not called)
11
Connect request
CLIv2 Connect
function
Request parcels
Response parcels
12
Disable logons
CLI CICS DISA

transaction
Request parcels
Response parcels

Table 1: Function Codes Descriptions (continued)
Function
Code
Function Name
Origin
Buffer content for

Request call Type
Buffer content for

Response call Type
13
Enable logons
CLI CICS DENA

transaction
(none)
(not called)
16
Start request
CLIv2 Initiate-request
function
Request parcels
Response parcels
17
Continue request
CLIv2 Fetch function
Request parcels
Response parcels
18
Continue-data
request
CLIv2 Continuerequest function
Request parcels
Response parcels
19
Abort-data request CLIv2 Continuerequest function
(none)
(not called)
(none)
(not called)
Cancel action
20
Abort Start request CLIv2 Abort function
32
Directed request
CLIv2 Directed-request Request parcels

function
Response parcels
36
Abort Directed
request
CLIv2 Abort function
(none)
(not called)
65
TDP command
z/OS subsystem
Command text
(not called)
command
TSO DBCCMD
command
66
TDP command,
CLIv2 Command
returning response function
Command text
Response parcels
68
Query Charsets
(not called)
(not called)
CLIv2 Query function

Available-character-sets
item
Developing Collection Applications

Your site is responsible for developing applications that process and analyze the data collected
by TDPUTCE.
Customizing TDPUTCE
Because TDPUTCE runs as part of TDP, it is privileged. If it is improperly coded, TDPUTCE
can cause errors or even destroy TDP.
When you customize a TDPUTCE module, consider the following points:
TDPUTCE can only access data supplied by TDP in data control blocks described in
MACLIB and SAMPLIB, on a release tape of Teradata software. It is not permitted access
to other TDP components.
57

The TDPUTCE module can directly use most normal OS services.
If TDPUTCE is abnormally terminated, TDP error recovery disables TDPUTCE, but once
the problem is resolved it can be reactivated using the TDP ENABLE TMON command.
On z/OS or VOS3, a dump is written to the TDPSNAP DDName. If the exit attaches tasks
not disabled and no dump is written by TDP. However, the operating system can record
TDPUTCE runs under TDP as a single-threaded routine, and can process only one request
at a time. Consequently, the routine must be at least serially reusable or re-enterable in
order to be compatible with the rest of TDP.
TDPUTCE can keep its own tables. As part of the parameter list between TDPUTCE and
TDP, a single word is always passed. Use of this word, which can be used to point to a block
of storage containing information required across calls, is completely under the control of
TDPUTCE.
As a subroutine of TDP, TDPUTCE must save and restore registers in the standard OS
format when it is called. If other services besides TDPUTCE also are called, the routine
must provide its own save area. Finally, TDPUTCE must return to the address passed in
general register 14.
Control is passed to the TDPUTCE routine with general register 1 pointing to the
TDPMNPRM control block. This control block contains a user word, the request/response
string, and pointers to fields containing information about the requestor.
When invoked to process a TDP command, any userids, passwords, and account names can
consist of characters from the character set passed to the exit. When supported by this
character set (or, for the START POOL command, in the command itself), each contiguous
group of EBCDIC double-byte characters is preceded by the Shift-out control character, X0E
and followed by the Shift-in control character, X0F. Neither commas nor blanks can be
specified as EBCDIC double-byte characters.
When invoked to process requests and responses, data (including object names) can contain
EBCDIC double-byte characters if double byte characters are valid in the session character set
passed to the exit.
Installing a Customized TDPUTCE Under z/OS or VOS3

You can install a customized TDPUTCE in the z/OS environment during normal TDP
operation.
Follow these steps to install a customized TDPUTCE under z/OS or VOS3, where <dbcpfx> is
your sites prefix for z/OS client modules:
58

User Security Interface
1
Rename the current version of TDPUTCE (either as originally supplied on the release tape
or as modified by your site) and retain it in the <dbcpfx>.TDPLOAD library. (This allows
the installation to back out erroneous load modules.)
Compile and link-edit the customized TDPUTCE module into the <dbcpfx>.TDPLOAD
library as TDPUTCE with the options RENT,REUS.
Install the customized TDPUTCE with SMP as a USERMOD to prevent overlaying the
customized module with a replacement TDPUTCE module supplied in a later software
release.

Introduction
Any return code from the Teradata Database that indicates an illegal or invalid attempt to
access data is intercepted and passed to TDP User Security Interface (TDPUSEC).
TDPUSEC Operation
TDPUSEC processes three types of calls:
Initialization
Security Violation
Terminate
The exit can be activated using the TDP ENABLE USEC command, either as part of TDP
DISABLE USEC command.
If the TDPUSEC module is replaced, the new version can be used by first deactivating the old
version using the TDP DISABLE USEC command then activating the new version using the
TDP ENABLE USEC command. Between the two commands, TDPUSEC is not being used.
The exit is initialized when an ENABLE USEC command is executed. During initialization,
TDPUSEC obtains a work area, opens files, and so on.
When a security violation call is received by TDPUSEC, it takes one of the following actions:
Sets a return code that indicates the following:
An error message is to be issued to the client operator and written to the system log,
and
A Security Violation SMF/SMS record is to be written (for z/OS or VOS3 only)
Returns control to TDP, which called TDPUSEC.
A terminate call is processed by TDPUSEC when TDP is disabled or a DISABLE USEC

command is executed. When this call is received the exit closes all files and cleans up all
resources.
For a coding example of the TDPUSEC routine, refer to the sample TDPUSEC that is shipped
with TDP.
59

The parameter list is described by the TDPUSPRM macro, which is distributed with the
product.
Customizing the TDPUSEC

When customizing a TDPUSEC module, consider the following points:
Because the TDPUSEC runs as part of TDP, it is privileged. If improperly coded, it can
cause errors or even destroy TDP.
The module can access only data supplied by TDP in data control blocks described in
MACLIB and SAMPLIB, on a release tape of Teradata software. It is not permitted access
to other TDP components.
The TDPUSEC module can directly use most normal OS services. WTO, WTL, and
SMFWTM services should be invoked by passing appropriate return codes to the caller of
TDPUSEC, TDP.
If the TDPUSEC routine is abnormally terminated, TDP error recovery disables

TDPUSEC and takes default actions (returning SMF record, log and system operator
messages, and error return code to the violating user), but once the problem is resolved it
can be reactivated using the TDP ENABLE USEC command.
On z/OS or VOS3, a dump is written to theTDPSNAP DDName. If the exit attaches tasks
not disabled and no dump is written by TDP. However, the operating system may record
TDPUSEC runs under TDP as a single-threaded routine, and can process only one request
at a time. Consequently, the routine must be at least serially reusable or re-enterable to be
compatible with the rest of TDP.
TDPUSEC may keep its own tables. As part of the parameter list between TDPUSEC and
TDP, a single word is always passed. Use of this word, which can be used to point to a block
of storage containing information required across calls, is completely at the option of
TDPUSEC.
As a subroutine of TDP, TDPUSEC must save and restore registers in the standard OS
format when it is called. If other services besides TDPUSEC also are called, the routine
must provide its own save area, and it must return to the address passed in general register
14.
Control is passed to the TDPUSEC routine with general register 1 pointing to the
TDPUSPRM control block. This control block contains a function code, a user word, and
pointers to fields containing information about the failed request.
On return, TDPUSEC passes a return code in general register 15 that requests any of the
following TDP actions:
60
Do nothing but return an error code to the caller.
In z/OS or VOS3, issue a WTO to the security console.

External Security Manager Interface
(z/OS or VOS3) Write a message to the system log and return an error code to the
caller.
(z/OS or VOS3) Write a TDP security violation SMF record and return an error code
to the caller.
(z/OS or VOS3) Abnormally terminate the caller (via cross memory ABTERM).
Any combination of these options can be chosen.

If the last option is chosen, however, the failure message is discarded without any attempt to
return it to the caller.
Installing a Customized TDPUSEC

You can install a customized TDPUSEC during normal TDP operation. Follow these steps to
install a customized TDPUSEC:
1
Rename the current version of TDPUSEC (this allows you to revert to the previous version
if necessary).
Compile and link-edit the customized TDPUSEC module into one of the following:
In z/OS or VOS3, the <dbcpfx>.TDPLOAD
Install the customized TDPUSEC with SMP as a USERMOD to prevent overlaying a

customized TDPUSEC with a replacement TDPUSEC module supplied in a later software
release.

Introduction
TDP provides an external security manager interface to the System Authorization Facility
(SAF) on z/OS client systems. External security managers such as RACF and ACF2 can use
SAF for logon validation and authorization, thus controlling access to the Teradata Database
without direct interaction with the RDBMS itself.
Using TDP and an external security manager, system security administrators can maintain a
separate external database or repository of resource profiles and access rules for the Teradata
Database, as well as for TSO, CICS, DB2, etc. This approach, called security logon,
significantly enhances the convenience and flexibility of system security administration.
Since SAF assumes all character data is in EBCDIC but a Teradata Database userid can be in
non-EBCDIC character sets, unexpected rejections or security exposures are possible. A
userid known to the external security manager in EBCDIC would not be recognized if
specified in ASCII. A userid specified in ASCII might consist of the same bytes as an EBCDIC
userid known to the external security manager and erroneously match. Such problems could
be circumvented by using different classes for userids encoded in different character sets. On a
request by request basis, the TDPLGUX exit can override the default class from the ENABLE
SECLOGON command based on the character set.
61

Security Logon Operation

The security logon operation is a four-stage process that involves:
TDP
The z/OS System Authorization Facility (SAF)
Your external security manager
The Teradata Database
At logon time, if the security logon function is enabled, TDP compares the Teradata
Database user id supplied by the logon application with the authid associated with the
requesting mainframe address space:
IF there is . . .
THEN . . .
a match, either explicit or

implicit (no Teradata
Database userid supplied)
TDP allows the logon to proceed with no further security

processing.
not a match
TDP sends logon validation and authorization requests to the

SAF interface to determine:
First, whether the user/authid is valid (validation)
And, if it is valid, whether the user/authid is allowed access
to the particular TDP (authorization)
The SAF interface routes the logon validation and authorization requests to the external
security manager.
The external security manager checks its own database or repository to identify the user
and verify access authorization.
The external security manager response to the SAF validation and authorization requests
indicates:
Whether the validation request succeeded or failed
Whether the authorization request was approved or disapproved
Any reason codes associated with a failed or disapproved request
Using Security Logon With TDPLGUX

The TDP security logon function and the User Logon Exit interface, TDPLGUX, can both
operate independently. But, because TDPLGUX can optionally modify both the authid and
the logon string itself, using them together can provide additional flexibility in security
administration.
When the security logon function is disabled, TDP allows a logon to proceed whenever
TDPLGUX returns a zero value. When the security logon function is enabled, the logon is
routed to TDP for final validation and authorization via the z/OS System Authorization
Facility (SAF) and your external security manager.
62

Note: Whenever TDPLGUX returns a nonzero value, TDP terminates the logon attempt,
immediately, whether security logon is enabled or disabled.
When using security logon with TDPLGUX, configure TDPLGUX to:
1
First, check flag bit LGSI$SEC in the LGISFL switch byte. This flag is ON when the security
logon function is enabled, signifying that TDPLGUX can place a modified authid in
LGICHUSR.
Then, after modifying the authid, set flag bit LGI$CHNG in the LGISFL switch byte to
ON. This signifies that TDP should use the new authid for logon validation and
authorization.
If necessary, override the default class in the LGICLASS field.
Note: By default, with no intervention by TDPLGUX, the authid is:
LGIXISU for most applications
LGIXIUSR for multiuser single-address-space applications such as CICS and IMS
Bypassing Security Logon

When using the security logon function with TDPLGUX, you can configure TDPLGUX to
bypass security logon for special maintenance-type authids. To bypass the security logon
function completely, for example, configure TDPLGUX to set the LGI$BYPS flag bit in the
LGISFL switch byte to ON.
Enabling/Disabling Security Logon

If you change the enabled/disabled status of the security logon function while TDPLGUX is
processing a logon request, TDP honors the configuration of the LGISFL switch byte as
follows:
If LGI$SEC was set to ON when TDPLGUX received control, and you disable the security
logon function while TDPLGUX is still in control, TDP will apply security logon to the
current request, but not to any subsequent requests.
If LGI$SEC was set to OFF when TDPLGUX received control, and you enable the security
logon function while TDPLGUX is still in control, TDP will apply security logon to all
subsequent requests, but not to the current request.
Using Security Logon With Session Pools

The security logon function is fully compatible with session pools.
Like TDPLGUX, security logon is not automatically invoked when you start a session pool. It
receives control when an application actually logs onto one of the sessions in the pool.
Note: Depending on how the session pool is defined at start-up, the application may still need
to provide a password to log on to a session in a particular pool, even though the security
logon function does not require a password.
63

Using Security Logon With The Validated Logon Function

The validated logon function allows applications to omit a password when logging on to the
Teradata Database from channel-attached client systems. (Logon requests from networkattached systems always require a password.) This function is also supported by the
TDPLGUX User Logon Exit interface and the TDPUAX Address Space Exit.
TDP security processing for validated logon requests can be handled by the security logon
function, or by TDPLGUX or TDPUAX, or any combination of the three, depending on your
system configuration.
Before any user can log onto the Teradata Database, the user name must be defined in the
database. A typical user name definition would be:
CREATE USER SAMPUSER AS PERM=10000000 PASSWORD=MYPASSWORD;
This would define user name SAMPUSER with ten megabytes reserved for tables and
associated data structures, and a logon password of MYPASSWORD. (The user definition
must include a password, even if you intend to use the validated logon feature.)
With this definition, the user could log on to the Teradata Database by specifying the TDPid
associated with the RDBMS, a user name of SAMPUSER, and a password of MYPASSWORD.
Before the user could omit the password from the logon string, per the validated logon
function:
The Teradata Database system administrator would have to grant logon access with a null
password.
The system security administrator would have to create the appropriate user resource
profiles or access rules in the external security manager application database.
See the setup procedure in the following subsection for a complete description of these tasks.
Security Logon Setup Procedure

Use the following procedure as a guideline for setting up and using the security logon
function:
1
Submit the following Teradata SQL statement to the Teradata Database to grant logon
access with a null password:
GRANT LOGON ON ALL AS DEFAULT
WITH NULL PASSWORD;
Note: This command must be submitted either by the Teradata Database system
administrator, or by another user with EXECUTE access to DBC.LogonRule.
Note also that:
64
The null password privilege only applies to logon requests originating on mainframe
client systems. Requests from network-attached workstations always require a
password.
Any attempt to log on to the Teradata Database with user name DBC always requires a
password. TDP will not use the validated logon feature for user name DBC.

The AS DEFAULT provision can be overridden by more restrictive GRANT clauses for
individual users.
If you have customized the User Logon Exit interface (TDPLGUX), then review the
interaction guidelines presented in subsection, Using Security Logon with TDPLGUX, to
determine whether additional changes are required.
If you have not customized TDPLGUX, its enabled/disabled status will have no effect on
security logon operations.
Set up your external security manager to work with the TDP security logon function.
For RACF:
a
Create user profiles in the FACILITY class with a universal access code of NONE to
regulate logons. Note, in the following example, that the first qualifier of the resource
name specifies the TDPid, and the second qualifier specifies the DBC user logon name:
RDEFINE FACILITY TDP9.TEST01 UACC(NONE)
RDEFINE FACILITY TDP0.BIG_DBC_USER_NAME
RDEFINE FACILITY TDPX.PAYROLL977263 -
- UACC(NONE)
UACC(NONE)
Give each user the appropriate status authority to the FACILITY profile. READ is
sufficient, as in the following examples:
PERMIT UACC(READ) USER(TSO0997) CLASS(FACILITY)
PROFILE(TDP9.TEST01)
PERMIT UACC(READ) USER(TSO0998) PROFILE(TDP0.DBC_BIG_USER_NAME) CLASS(FACILITY)

PERMIT UACC(READ) USER(TSO0999) CLASS(FACILITY)
c
PROFILE(TDPX.PAYROLL977263)
If you have not already done so, activate the FACILITY class:
SETROPTS CLASSACT(FACILITY)
For ACF2
Set up resource rules of TYPE(FAC) to regulate logon requests and grant access to each
user. Note, in the following example, that the key represents the TDPid and the extension
represents the DBC user logon name:
SET RESOURCE(FAC)
COMPILE *
$KEY(TDP9) TYPE(FAC)
TEST01 UID(TSO997) ALLOW
STORE
COMPILE *
$KEY(TDPX) TYPE(FAC)
STORE
COMPILE *
65

$KEY(TDPX) TYPE(FAC)
PAYROLL977263 UID(TSO999) ALLOW
STORE
For all other external security managers:
Refer to the appropriate vendor documentation.
4
Always test new resource profiles or access rules before placing them in a production
environment.
Because the FACILITY class is limited to 39 bytes, it will not suffice if RDBMS user names
exceed 30 bytes. This will be the case only if character sets are being used that support
more than one byte per character. If this is the case, you will have to create an entirely new
class with a maximum length of 92 bytes (the maximum number of bytes for an RDBMS
user id in any currently supported character set).
This is a complicated processespecially under RACF, where an IPL will be
requiredand should be performed only by an experienced systems programmer.
Refer to the appropriate vendor documentation for details, and when the security logon
function is enabled, specify the name of your new alternate class as follows:
ENABLE SECLOGON MSGS CLASS DBCLOGON
This forces TDP to use a class name of DBCLOGON instead of FACILITY for RACROUTE
authorization calls.
Note: Under RACF, class names can be between 4 and 8 characters in length. Under ACF2,
class names are called resource names and are generally 3 characters in length. (ACF2
internally translates FACILITY to FAC, and vice versa.)
5
Enable the security logon function with the desired messages option:
ENABLE SECLOGON MSGS
or:
ENABLE SECLOGON NOMSGS
See Chapter 4: Customer Exits and Teradata Userid Authentication, for more information
about the TDP commands that pertain to the security logon function:
66
ENABLE SECLOGON
DISABLE SECLOGON
MODIFY SECLOGON
CHAPTER 5
The Release Tape
This chapter describes how to find files distributed on the release tape after TDP is installed:
TDPXRC
TDPXRC defines the return codes that can be returned by TDP for a request or its response.
For this Language...
The definition for TDPXRC is located in the...
IBM Assembler
TDPXRC in library SAMPLIB (if z/OS).
67
Chapter 5: The Release Tape

TDPXRC
68
CHAPTER 6
TDP Operation
This chapter describes TDP operation. It should be used by:
Operators who manage the Teradata Database
System programmers who create the TDPPARM data set
End users
Unless stated otherwise, this information applies to all environments.
Starting a TDP Under z/OS or VOS3

To start a TDP, use the following general steps:
1
Check that the <dbcpfx>.TDPLOAD library at your site is APF-authorized.
Check that the TDPISSI module was run and completed at IPL time.
(Optional) Customize the TDPPARM data set, if necessary.

For example, you may want to customize the TDPPARM data set if you have installed a
new TDP or if you want to make a change in the initialization options.
Start the TDP task, typically with the same name as the tdpid.
Examples of TDP startup JCL are included in <dbcpfx>.PROCLIB, with the member
names of TDP0 and TDP1.
On z/OS and VOS3 systems, TDP establishes the following exclusive system-wide
serialization during its execution:
Major Name
Minor Name
Purpose
TERADATA
4byte EBCDIC tdpid
Prevents multiple TDPs with the same

id.
TERADATA
8byte EBCDIC HOSTxxxx,

where 'xxxx' is the hexadecimal
Prevents multiple TDPs from using the

same Database logical host.
logical host id converted to

EBCDIC
On z/OS, TDP does not inhibit use of Resource Name Lists (RNLs) to alter the scope of the
serialization. So if the mainframe configuration consists of a sysplex capable of accessing
the same Database logical hosts, z/OS Global Resource Serialization can be used to extend
69
Chapter 6: TDP Operation

Initializing a TDP
the local TDP serialization to all system images by including the major and minor names
into the System Inclusion RNL.
For more detailed information on starting a TDP, see Teradata Tools and Utilities Installation
Guide for IBM z/OS.
Initializing a TDP
Introduction
After TDP starts, it can be initialized to communicate with the Teradata Database. The
environment in which TDP is to operate is defined using TDP operator commands.
The TDP operator commands can be entered manually from a console or automatically in the
TDPPARM data set.
Minimally, the following TDP operator commands are necessary:
START CP (one for each Teradata channel processor that communicates with TDP)
ENABLE LOGONS (to allow users to log on to TDP)
RUN (to begin the execution phase of TDP operation; allows TDP commands, including
the ones currently queued, to be executed)
You can use additional operator commands, such as INITIAL commands, to further define
the TDP environment.
Entering Initialization Commands From TDPPARM

The TDP parameter (TDPPARM) data set can be used in any client to automatically issue all
or some of the initialization commands when TDP is started. Each TDP can have its own
TDPPARM data set, which can contain any TDP command.
The following TDPPARM examples are included on the appropriate release tape:
Operating
System
TDPPARM Example Name
z/OS
Members TDPCMD0 and TDPCMD1 in <dbcpfx>.PROCLIB
VOS3
TDPPARM for z/OS and VOS3

In the z/OS or VOS3 environment, the job that starts TDP contains the TDPPARM DD
statement, which identifies the member name of the TDPPARM data set. In the examples on
the release tape, the TDP0 job calls TDPCMD0, and the TDP1 job calls TDPCMD1. Typically,
the name of the job that starts TDP is the same as the tdpid.
70

Initializing a TDP
Creating Your Own TDPPARM

If you do not want to use the examples on the release tape, you can create your own
TDPPARM data set. It can be any data set that contains fixed, 80 byte records consisting of
EBCDIC characters and is accessible to IBMSAM (Queued Sequential Access Method).
Columns 73 through 80 are reserved for traditional sequence numbers and are ignored.
Records containing only blanks are ignored. If the first non-blank characters of a record are /*,
the record is considered a comment and ignored.
Messages that result from executing commands in the TDPPARM data set are routed to the
MVS console at which TDP was started. The records can be maintained by any text editor or
utility that honors these attributes. If TDP was started as a batch job, messages are routed to
the master console route code.
If execution of any TDPPARM command results in an error, TDP displays:
TDP0113 INITIALIZATION ERRORS -- ENTER GO OR CANCEL
If you enter GO,TDP continues to run. CANCEL stops TDP. The source of the error(s) can
be determined either from the responses displayed at the console or from the dump.
TDPPARM is read only when TDP is started. Once all records have been processed,
TDPPARM is not read again.
TDP Internal Sessions for Two Phase Commit

When TDP is initialized, two internal sessions are logged on to the Teradata Database with the
userid, TDPUSER. The TDPUSER name can be changed using the SET USERID command
(see SET USERID on page 206). By default, the userid is in EBCDIC, but a different
character set can be specified using the SET CHARSET command (see SET CHARSET on
page 198). The current userid and character set can be displayed using the DISPLAY TDP
command (see DISPLAY TDP on page 152). Any new userid that is substituted for
TDPUSER must have the EXECUTE privilege on the DBC.TwoPCRule macro in DIPVIEWS.
This privilege typically is set by the DBA for your site.
For more information on 2PC and the DBC.TwoPCRule macro, see one of the following:
Database Design
Database Administration
The two TDP-internal sessions are used for in-doubt resolution of 2PC transactions. They are
established when TDP is started, and remain until TDP is shut down. These internal sessions
can appear on any TDP command display that lists session-related information, such as the
output from the DISPLAY SESSIONS command. The internal sessions appear in the displays
with the following job name:
*TDPINT*
These two internal sessions comprise the In-doubt Resolution Facility (IRF) for 2PC. In order
to run 2PC applications, you must have IRF enabled.
In-doubt resolution can be disabled using the DISABLE IRF command to achieve a LOGON/
QUIET status on the RDBMS console. However, if IRF is disabled, your 2PC applications will
71

Entering TDP Commands
not run. Note that to disable the two internal sessions, you must use the DISABLE IRF
command, not the Performance Monitor ABORT SESSION command.
Entering TDP Commands

The TDP accepts operator commands from the z/OS console, MVS/TSO users, VOS3/TSS
users, and CLIv2 applications.
As with commands entered from TDPPARM, commands entered from the console are not
executed until the RUN command is executed. Messages that result from executing operator
commands entered from a console are returned to the console.
Commands issued by an operator, an application, or TDP itself are recorded in the TDP
joblog. When responses are written to the console or system log, sometimes the joblog is not
perfectly ordered. Specifically, the command and its response can be reversed. When a START
POOL command containing a logon string is echoed, all text after the LOGON operand is
echoed as asterisks to prevent display of any password in the logon string.
Entering TDP Commands on z/OS and VOS3

Introduction
The TDP accepts operator commands from the z/OS console and from MVS/TSO or VOS3/
TSS users.
Entering TDP Commands from the z/OS or VOS3 Console

The MODIFY command can be used from the console to issue TDP operator commands to a
TDP that is already running in the z/OS or VOS3 environment. This has the advantage of not
requiring TDP PC cells to execute. The syntax of the MODIFY command is:
F tdpid,TDPcommand_text
where:
Syntax Element
Description
Abbreviation for the z/OS MODIFY command.
tdpid
Four-character identifier associated with the TDP subsystem (for

example, TDP0, TDP1, and so on) to which the command is directed.
TDPcommand_text
Syntax of the TDP command.
Entering TDP Commands From z/OS/TSO or VOS3/TSS

TDP accepts commands from the console or any user that has the authorization to execute the
commands. The TDP commands can be executed in the TSO foreground or background by:
72

Using a TSO CALL command to call the DBCCMD user interface
Using the DBCCMD CLIST that is supplied on the release tape
Invoking the DBCCMD program from within batch jobs
The standard application-to-TDP interface routine supports routing a command from the
MVS/TSO or VOS3/TSS address space to the requested TDP subsystem.
Using a TSO CALL Command

The parmstring used as the input argument to DBCCMD is composed of the name of the
subsystem TDP to which the command is to be sent, followed by the text of the TDP
command.
The syntax of the statement is:
CALL loadlib(DBCCMD) tdpid TDPcommand_text
where:
Syntax Element
Description
loadlib
Name of the load library containing DBCCMD.
tdpid
Four-character TDP subsystem identifier.
TDPcommand_text
Text of the command to be executed by TDP.
The parmstring that includes the tdpid and the command text should have a maximum length
of 120 characters, enclosed in single quotation marks.
Using the DBCCMD CLIST

To simplify the calling sequence, you can use the supplied CLIST of the same name,
DBCCMD, to build the parmstring and call the DBCCMD module. The DBCCMD CLIST
accepts the parmstring as the argument to the CMD keyword as follows:
DBCCMD CMD(tdpid TDPcommand_text)
where:
Syntax Element
Description
tdpid
Four-character TDP subsystem identifier.
TDPcommand_text
Text of the command to be executed by TDP.
Invoking DBCCMD From a Program

DBCCMD expects standard OS linkage conventions, described in the IBM publication MVS
Supervisor Services and Macros Manual. The TSO CALL command invokes the called program
73

using these conventions. In particular, Register 1 should point to a parameter list, and other
registers to different areas, as follows:
Register
Description
R1
Pointer to parmlist.
R13
Pointer to a 72-byte save area (will be used).
R14
Return address to calling program.
R15
entry address of DBCCMD.
Construct the parmlist and argument as follows:

parmlist:
1 full word containing address of argument. (Bit 0 should be set to b1 to

indicate the last parameter.)
argument:
+0: 2-byte length of following parmstring.

+2: command parmstring, as described earlier.
DBCCMD Return Codes

DBCCMD validates the input parameters. If the command is used in the background, any
response is sent to the TDP console log. If the command is run in the foreground, DBCCMD
responds with a return code or an error code. Possible return and error codes are as follows:
Return Code
Meaning
Command was successfully sent to target TDP.
Required input parameter is missing or invalid.
Required tdpid argument is missing or invalid.
12
Required command text argument is missing.
264
Target TDP does not support the command facility.
280
Target TDP was not found.
282
Target TDP was not available.
Since DBCCMD essentially uses the same interface that CLI uses to send work to TDP, the
DBCCMD interface performs the same validation as it does for any CLI-to-TDP request. Any
error codes returned other than those listed above would, therefore, indicate an internal error
in DBCCMD.
74

Entering TDP Commands from CLIv2 Applications
Viewing Command Responses

TDP returns the command response to the issuing foreground user via cross-memory TPUT.
This is the same interface used by the SEND command. The response, therefore, appears on
the terminal screen as similar to any message returned to the application by TDP using the
SEND command.
Entering TDP Commands from CLIv2

Applications
To issue TDP operator commands from within CLIv2 programs, you must use the CMD
function available in CLIv2. For details, refer to the section on the CMD function in Teradata
Call-Level Interface Version 2 Reference for Mainframe-Attached Systems.
Types of TDP Command Responses

Introduction
TDP commands usually cause TDP to generate at least one, and sometimes two types of
responses.
Immediate Response Commands

The first is the immediate command response type, in other words, a direct and immediate
response to the command. For example, a display command causes TDP to generate a direct
display response, or a direct error message response.
Process-Oriented Commands
Certain TDP commands, however, initiate a process or modify the state of a process. For
example, a START CP command causes TDP to go through the device startup sequence. In
such a case, TDP first returns an immediate response, essentially indicating whether the
command was accepted or not. If the command is accepted, TDP monitors the completion of
the process.
After the requested process has completed, TDP then sometimes issues an asynchronous
status message describing the results of the process. This message is not considered a
command response, and is not therefore routed to the originating userid. Instead, the message
displays on the TDP console. (In most cases the user can enter other TDP display commands
to obtain the new status of the process.)
75

TDP Operator Message Character Set
TDP Operator Message Character Set

In a multibyte character environment, the text of operator messages produced by TDP
contains only valid EBCDIC graphic characters (in the range of X40 through XEF).
Other characters are replaced by a hyphen before the message is issued. The only exceptions
are the control characters Shift-out and Shift-in, which are replaced by the less than (<) and
greater than (>) characters, respectively.
When more than one byte comprises a character, each byte is replaced by a hyphen. So the
number of hyphens reflects the number of bytes, not the number of characters.
Shutting Down a TDP

Introduction
The SHUTDOWN operator command (for details see SHUTDOWN on page 208.) allows
you to shut down a TDP in one of the following ways:
Type of Shutdown
TDP Action
Orderly
Waits for all user sessions to end before shutting itself down normally.
Quick
Forces a logoff of all sessions before shutting itself down normally.
Cancel
Shuts itself down immediately.
Canceling a TDP Under z/OS or VOS3

In addition to the SHUTDOWN command, you can also use the CANCEL command to shut
down a TDP. For example, to cancel a TDP named TDP1, you could use the following
command:
CANCEL TDP1
The effect of this command is similar to that of the Cancel form of the SHUTDOWN
command.
When shutting down a TDP, you can use the CANCEL command to generate a dump. For
example, to cancel TDP1 and generate a dump, use the following command:
CANCEL TDP1,DUMP
Using PC IACMODE on MVS SP release 4.3 or later always produces the
following message when TDP is shut down:IEF352I ADDRESS SPACE
UNAVAILABLE
This is a normal result of z/OS requirements when using a system linkage index. It does not
indicate an error in either TDP or z/OS.
76

Regulating Authority to Issue TDP Commands
Regulating Authority to Issue TDP Commands

Introduction
The distribution of authority to issue TDP commands is a site-specific issue. Following is a
description of the authorization capabilities featured in TDP.
Levels of Command Issuing Authority

There are five levels of command-issuing authority that you can grant to a user:
NONE
DISPLAY
ANY
AUTHORIZ
RESOLVE
AUTHORIZ Command
With the AUTHORIZ command you can grant:
Authority to one, many, or all users
Any or all of the five authority levels
For details, see AUTHORIZ on page 93.
User Validation
To validate users, TDP performs the following steps:
1
Determines if the user entry is a valid TDP command.

IF the command is . . .
THEN TDP . . .
not a valid TDP command
returns the standard syntax error message to the source

virtual machine or user.
a valid TDP command
validates the authority of the userid to issue that specific

command.
Verifies if a user is authorized to issue a specific command by searching for a matching

userid listing in an existing internal table.
IF the userid is . . .
THEN TDP . . .
listed in the table
confirms that the user is authorized to issue the command.
77

Session Pools
IF the userid is . . .
THEN TDP . . .
not listed in the table
reverts to a default authority to determine whether the

userid is valid, and if so, if such a user is authorized to issue
the command.
The TDP command is then accepted and processed, or
rejected with an error message, based on this default
validation process.
Session Pools
Introduction
A session pool is a number of sessions that are logged on to the Teradata Database as a unit
using the same logon string. Unlike ordinary sessions, pool sessions are automatically assigned
to applications that initiate a logon using the same logon string as that established for the
pool.
Logging Pool Sessions on to the Teradata System

The sessions in a pool are logged on to the Teradata Database once using the START POOL
operator command (for details see Chapter 7: TDP Commands) and remain logged on until
they are explicitly logged off by the STOP POOL (or STOP POOL and LOGOFF POOL)
operator commands.
When a pool is first established, all pool sessions are not in use. When an application sends a
logon request whose logon string matches that of the session pool, as described below, the
application is assigned an available session from the pool. This results in a quick logon,
because the applications logon request does not have to be sent to the Teradata Database.
The session assigned to the application is marked in-use and cannot be reassigned to
another application until the current application logs off. The logoff returns the session to the
pool, where it becomes available for use by another application.
Multiple Simultaneous Session Pools

Many session pools can exist at the same time, each having a unique logon string. The logon
string contains a logon id, password, and, optionally, an account identifier.
Several pools can be established using the same logon id and password, but with different
accounting information. The same logon string can be used to establish a number of pools,
each devoted exclusively to the applications that belong to a different job.
For example, a logon string might be used to establish one session pool for a CICS job,
another pool for another job. Thus, each pool would be considered to have specific job or
session attributes.
When an application logs on, the following verification process occurs:
78

Session Pools
1
The logon string of the application is checked to determine whether it matches that of any
established pool.
IF TDP . . .
detects a matching
logon string
THEN it . . .
checks the pool to determine whether there is are specific job or
session attributes.
IF there is . . .
THEN the . . .
are specific job or session

attributes that match that of the
application
application is assigned a session

from the pool if there is a session
available.
are no specific job or session

attributes
search continues to determine

whether any other existing pool
has both the logon string and
specific job or session attributes
that match the application.
If no pool is found, and if there
is an available pool, then TDP
assigns a session from the pool
with the matching logon string
and no specific job or session
attributes.
does not detect a

matching logon
string
2
TDP sends the logon for the application to the Teradata Database.
TDP assigns a session pool.

IF a matching pool is
found and . . .
THEN TDP . . .
there is no session
available in the pool
to satisfy the
applications logon
request
rejects the request with an error message.
sessions are available
assigns the application a session.
it has a specific job or

session attributes
and no available
sessions or the pool
is disabled
rejects a logon request with a matching logon string and job.

This is true even if there exists another pool with the same logon string
and available sessions, but no specific job or session attributes.
Session Logoff Process

The following process occurs when the application logs off the session.
79

Session Pools
1
The Teradata Database is not notified that the session has been logged off.
TDP removes the session from the in-use category and returns it to the not-in-use
category.
If a STOP POOL command (or a MODIFY POOL command to reduce the number of
pool sessions) is entered while the session is in use, the session is logged off of the Teradata
Database.
If the database to be used by the application differs from the database associated with the
logon string of the pool, the application must either change the default or fully qualify all
table references.
If an application either abends or a session logs off from a session pool, the system does a
clean up as follows:
Deletes all spool files
Releases all locks
Reestablishes the default database
If an ENABLE POOL DETAIL command has been issued, messages indicate why a session is
not satisfied from a session pool.
If an ENABLE POOL STATUS command has been issued, a TDP0802 message indicates if a
session is satisfied from a session pool.
If an ENABLE POOL STATUS command has been issued, a TDP0803 message indicates if a
session that had been satisfied from a session pool ends.
80
CHAPTER 7
TDP Commands
This chapter describes TDP operator commands and INITIAL commands used to control
TDP operation. It should be used by:
Operators who manage the Teradata Database
System programmers who create the TDPPARM data set
End users
Refer to Appendix D: How to Read the Syntax Diagrams, for information on syntax
diagrams.
Unless stated otherwise, this information applies to all environments.
TDP Operator Commands

How to Issue TDP Operator Commands
As discussed before, you can issue TDP operator commands from:
The TDPPARM data set
The system console before the RUN is executed
The system console during normal TDP operation
An authorized userid
TDP Operator Command Descriptions

The sections that follow contain detailed descriptions of each TDP operator command, listed
alphabetically. Each command description includes:
A brief explanation of the command function
The command syntax
Usage notes that describe how the command operates and how it can be used
An example of a command entry
The normal completion message to expect
For display commands, an example result is also included
Table 2 lists TDP operator commands and summarizes their function.
81
Chapter 7: TDP Commands

Table 2: TDP Operator Commands
Command
Function
ADD CELLS/XMSCELLS
Adds cells of main memory or cross memory PC cells to a TDP.
ATTACH CP
Allocates a specified channel device from the operating system.
ATTACH IFP (Deprecated by

ATTACH CP)
Deprecated: convert to ATTACH CP.
COMMIT
For 2PC sessions, commits the changes in the specified in-doubt

sessions.
DETACH CP
Deallocates a specified channel device from the operating system.
DETACH IFP (Deprecated by the

DETACH CP command)
Deprecated: convert to DETACH CP.
DISABLE IRF
Logs off TDP internal sessions that are used for 2PC in-doubt
resolution.
DISABLE LGUX
Causes TDP to stop passing logon requests to the User Logon

Exit Interface (TDPLGUX).
DISABLE LOGONS
Causes TDP to stop accepting requests from applications. Logons

are not enabled when TDP starts.
DISABLE POOL
Prevents logons to one or more pools.
DISABLE POOL DETAIL
Disables POOL DETAIL.
DISABLE POOL STATUS
Disables POOL STATUS.
DISABLE SECLOGON
Disables the security logon interface to the System Authorization

Facility (SAF) on z/OS Client systems.
DISABLE SESSION DETAIL
Stops TDP from producing messages that indicate the elapsed

time spent in the application and on the Teradata Database
when a session ends.
DISABLE SESSION RESERVE
Causes TDP to release the reserved session capacity so that

customer applications can use the maximum session capacity
supported by the Teradata Database.
DISABLE SESSION STATUS
Stops TDP from producing messages when a session starts or

stops.
DISABLE SMF
Prevents SMF information from being recorded.

In the VOS3 environment, applies to SMS records.
82
DISABLE TDPSTATS
Causes TDP to stop collecting performance data.
DISABLE TEST
Causes TDP to stop writing the informational/diagnostic

messages generated by TEST mode to the system console. TEST
mode is not enabled when TDP starts.
DISABLE TIME
Prevents TDP from sending time to the Teradata Database.

Table 2: TDP Operator Commands (continued)
Command
Function
DISABLE TMON
Disables TDP calls to the User Transaction Collection Exit

(TDPUTCE), which is enabled when TDP starts.
DISABLE TRAP
Stops a TDP diagnostic trap.
DISABLE UAX
Causes TDP to stop accepting requests from the user address

space exit.
DISABLE USEC
Causes TDP to stop passing security/ logon violations

information to the User Security Interface (TDPUSEC), which is
enabled when TDP starts.
DISPLAY CCU
Displays information related to the operation of CPs started with

the CCU operand.
DISPLAY CELLS
Displays all availability and usage information generated by the

TDP internal memory management system.
DISPLAY CHECKSUM
Displays the status of checksum validation of data transfers to

and from the Teradata Database when using CCU-type CPs
DISPLAY CP
Displays the status of one or more channel processors (CPs).
DISPLAY IFP (Deprecated by the

Display CP command)
Deprecated: convert to DISPLAY CP.
DISPLAY INDOUBT
For 2PC sessions, displays any in-doubt sessions or any

coordinators that have in-doubt sessions.
DISPLAY JOB
Displays the status of jobs that are communicating with the

Teradata Database through TDP.
DISPLAY LIMIT
Displays information related to TDP limits.
DISPLAY MODULE
Displays information about a TDP module.
DISPLAY POOL
Lists information and statistics about session pools.
DISPLAY QUEUES
Displays the status of internal work queues for a TDP.
DISPLAY SERVER
Displays attributes of the Teradata Database with which TDP is

communicating.
DISPLAY SESSIONS
Displays the status of sessions that are communicating with the
Teradata Database through TDP.

DISPLAY SMF
Displays the status of SMF recording.

DISPLAY SP
Displays the status of one or more session processors (SPs).
DISPLAY STORAGE
Displays information about the use of virtual storage by TDP.
DISPLAY TDP
Displays the status of TDP.
DISPLAY TDPSTATS
Displays the status (enabled or disabled) of TDPSTATS.
83

Command
Function
ENABLE IRF
Logs on TDP internal sessions that are used for 2PC in-doubt
resolution.
ENABLE LGUX
Causes TDP to begin passing logon requests to TDP User Logon

Exit Interface (TDPLGUX).
ENABLE LOGONS
Causes TDP to begin accepting logon requests from applications.

Logons are not enabled when TDP starts.
ENABLE POOL
Enables logons to one or more pools.
ENABLE POOL DETAIL
Enables POOL DETAIL.
ENABLE POOL STATUS
Enables POOL STATUS.
ENABLE SECLOGON
Enables the security logon interface to the System Authorization

Facility (SAF) on z/OS Client systems.
ENABLE SESSION DETAIL
Causes TDP to produce messages that indicate the elapsed time

spent in the application and on the Teradata Database when a
session ends.
ENABLE SESSION RESERVE
Causes TDP to reserve session capacity for recovery processing in

the event of the failure of an SP, thus reducing the maximum
number of sessions that it can control during its current run.
ENABLE SESSION STATUS
Causes TDP to produce messages when a session starts or stops.
ENABLE SMF
Causes SMF information to be recorded.

ENABLE TDPSTATS
TDP to begin collecting performance data.
ENABLE TEST
Causes TDP to start writing the informational and diagnostic

messages generated by TEST mode to the system console.
TEST mode is not enabled when TDP starts.
84
ENABLE TIME
Causes TDP to send time to the Teradata Database.
ENABLE TMON
Enables TDP calls to the User Transaction Collection Exit

(TDPUTCE), which is enabled when TDP starts.
ENABLE TRAP
Establishes a TDP diagnostic trap.
ENABLE UAX
Causes TDP to pass requests to the user address space exit.

Currently, only connect or logon requests are passed.
ENABLE USEC
Causes TDP to start passing security/ logon violations

information to the User Security Interface (TDPUSEC), which is
enabled when TDP starts.
INITIAL CCU
Change limits used by CCU-type CPs.

Command
Function
INITIAL DLYTIME
Indicate interval for issuing reminders that all communication

with the Teradata Database has been lost. For compatibility
with prior releases, this parameter can also be specified as
INITIAL RSTTIME.
INITIAL IACMODE
Choose the mode of communication between TDP and an

application program.
INITIAL IOBUFS
Change the number of I/O buffers for CPs not requiring the CCU
operand on the START command.
INITIAL IOMODE
Choose the mode used by TDP for sending I/O to the Teradata
Database.
INITIAL JOBWAIT
Choose the amount of time that an application can be in a wait

state before TDP initiates an activity to prevent the application
from being timed out by the operating system.
INITIAL LSQA
Control the use of LSQA in address spaces communicating with

the RDBMS.
INITIAL MAXSESS
While still functional, this command has been replaced by the

SET MAXSESS command.
INITIAL MSGPREF
Control the TDP identifier that normally appears before the

message prefix.
INITIAL OSSISUFX
Associate a TDP with the version of HSIOSSI (if SVC mode) or

HSISXMS (if PC mode) that is used by the subsystem in which
the TDP is to run.
INITIAL PCSUFX
Associate a TDP with the version of the TDPNSPCI module that

is used in the TDP subsystem.
INITIAL RSTTIME
INITIAL DLYTIME has replaced this command.
INITIAL TRUNCRSP
Specifies if truncation of a response is to be indicated by a return

code.
INITIAL USERID
While still functional if the USERID uses the EBCDIC character

set, this command has been replaced by the SET USERID
command, which supports all character sets.
LOGOFF
Forces one or more sessions to be logged off the Teradata
Database.
LOGOFF POOL
Ends a pool immediately by forcing the logoff of pool sessions

that are in use by application programs.
MODIFY POOL
Increases or decreases the number of sessions in a pool.
MODIFY SECLOGON
Changes the messages display option for the security logon

interface to the System Authorization Facility (SAF) on z/OS
Client systems
85

86
Command
Function
RESOLVE
For in-doubt two-phase commit sessions, manually resolve the

in-doubt status.
ROLLBACK
For 2PC sessions, rolls back the changes in the specified in-doubt
sessions.
RUN
Causes operator commands entered from TDPPARM or the

system console to be executed.
SET CHARSET
Establishes the character set with which userids and logon strings
are specified in TDP commands.
SET CHECKSUM
Changes the use of checksum validation for data transfer to and

from the Teradata Database through CCU-type CPs.
SET COMCHAR
Establishes or changes the communication character that is used

to link operator command entry with a TDP to be initialized.
SET LIMIT
Establishes limits used by TDP.
SET MAXSESS
Establishes the maximum number of sessions that TDP can

control during its current run.
SET STORAGE
Changes the virtual storage limits used by TDP.
SET USERCS
Establishes characteristics of a user-defined character set that is

available on the Teradata Database.
SET USERID
Establishes the Database userid for TDP internal sessions.
SHUTDOWN
Stops TDP operation.
START CP
Causes TDP to begin communicating with the Teradata Database

using a specified channel device.
START IFP (Deprecated by the

START CP command)
Deprecated: convert to START CP.
START POOL
Establishes and enables a session pool.
STOP CP
Ends communication with the Teradata Database using a

specified channel device.
STOP IFP (Deprecated by the

STOP CP command)
Deprecated: convert to STOP CP.
STOP POOL
Ends one or more session pools in an orderly manner.

ADD CELLS/XMSCELLS
ADD CELLS/XMSCELLS
Purpose
Adds cells of main memory to a TDP for its internal use.
The ADD XMSCELLS command can be specified in the z/OS environment to increase the
number of cells reserved for use by the IOMODE PC interface to transfer data between the
application and TDP address spaces.
Except for a small number of cells used for specialized purposes, all cells are allocated from
31bit storage
Syntax
ADD
CELLS
XMSCELLS
SIZE
cellsize
SIZ
NUMBER
NUMBER
number_of_cells
NUM
number_of_cells
SIZE
NUM
SIZ
cellsize
FZAPB001
where:
Syntax Element
Description
CELLS
Specification that the maximum number of cells are to be increased.
XMSCELLS
Specification that the number of cells reserved for use by the IOMODE PC
interface are to be increased.
cellsize
Size, in decimal, of the cells to be added.

Range is 1 through 32760.
number_of_cells
Number, in decimal, of cells to be added.

Size range is 1 through any multiple of 16.
Usage Notes
The ADD CELLS and ADD XMCELLS commands can be used to improve TDP throughput
when throughput has degraded. Use the DISPLAY CELLS command to display excessive
GETMAIN or wait counts, which can reduce TDP throughput.
Note that the size argument must specify an existing cell size. To obtain the cell size, issue the
DISPLAY CELLS command. Add numberofcells to the cellsize cell pool by issuing the ADD
command.
XMSCELLS are used in z/OS only.
87

ADD CELLS/XMSCELLS
Example
ADD CELLS SIZ 80 NUM 16
Completion Message
TDP0527 16 MEMORY CELLS OF SIZE 80 SUCCESSFULLY ADDED
88

ATTACH CP
ATTACH CP
Purpose
Allocates a specified channel device from the operating system.
Syntax
ATTACH
ATT
cpname
2416A005
where:
Syntax Element
Description
cpname
Pair of Database communication devices specified as CPnnnn, where nnnn is

the device number of the even-numbered device. Either three or four
hexadecimal digits can be specified.
Usage Notes
The devices for an IFP can be either explicitly or dynamically allocated. Dynamic allocation by
TDP is the normal choice since only the ATTACH command is required. Explicit allocation
requires that the following be performed before the ATTACH command is issued:
If using this
operating system . . .
z/OS
VOS3
Do the following . . .
In the JCL procedure used to start TDP, include one DD statement for each
of the two devices for the CP. Each is of the form:
//IFPnnnn DD UNIT=nnn
In one DD statement the nnn is the even device. In the other DD statement
the nnn is the odd device number.
For four-digit device numbers, z/OS requires that the UNIT parameter
contain a slash as in UNIT=/nnnn
Before TDP will use the CP, a START command for that CP and a RUN command must be
issued and complete.
Example
ATTACH CPC308
Completion Message
The following message confirms that the command has been validated:
89

ATTACH CP
TDP1356 ATTACH COMMAND ACCEPTED FOR CPC308
The following message subsequently confirms that the command has been completed:
TDP1356 "CPC308" HAS BEEN ATTACHED
90

ATTACH IFP (Deprecated by ATTACH CP)

Purpose
Allocates an CP to a TDP.
Syntax
ATTACH
ATT
cpname
2416A005
where:
Syntax Element
Description
cpname
CP as IFPnnnn, where nnnn is the device number of the even-numbered CP

or device, in three or four hexadecimal digits.
Usage Notes
The devices for a CP can be either explicitly or dynamically allocated. Dynamic allocation is
the more usual operation since no explicit allocation is required: TDP automatically allocates
the required devices. Explicit allocation requires that the following be performed prior to
ATTACHing the CP:
If using this
operating system . . .
z/OS
Include two DD statements in the JCL procedure that is used to start TDP.
VOS3
The DD statements should be in this format:
// IFPnnnn DD UNIT=nnn
One of these statements is for the even CP device number, the other for the
corresponding odd CP device number.
If a four-digit device number is specified for the UNIT keyword, z/OS
requires that a slash precede the digits, as in UNIT=/nnnn
The FILEDEFs should be in this format:
FILEDEF IFPnnnn DUMMY IFP nnnn I
For either operating system, IFPnnnn corresponds to the ifpname used in the ATTACH
command. IFPnnn and IFP0nnn are equivalent. That is, the command can specify one form
and the static system definition can specify the other.
91

Before any session can be assigned to a newly attached CP, the following must occur:
The RUN command must be executed
A START CP command must be executed for the CP
TDP must respond with an IFP STARTED message
Because an CP is implicitly attached to a TDP by the RUN/START CP command execution

sequence, the explicit use of the ATTACH CP command is unnecessary under normal
operating conditions.
Example
ATT IFP490
Completion Message
TDP1356 IFP490 ATTACHED
92

AUTHORIZ
AUTHORIZ
Purpose
Grants authority to users at any or all of the five authority levels.
Syntax
NONE
AUTHORIZ
AUT
ALL
userid
DISPLAY
job
D
ANY
A
AUTHORIZ
AU
RESOLVE
R
FZAPB074
Note: The AU abbreviation is deprecated.

where:
Syntax Element
Description
userid
Virtual machine name

MVS/TSO userid for foreground MVS/TSO,
VOS3/TSS userid, or
z/OS or VOS3 jobname (IMS control region or CICS job).
ALL
Way to set the default authority for all users for whom no other specific
authority has been granted.
Note that the ALL authority does not imply RESOLVE or AUTHORIZ; those
authorities are set separately.
job
Jobname for the 2PC job (IMS control region or CICS job) that is being
authorized.
NONE
Way to deny authority to issue TDP commands to the specified userid(s) or to

ALL.
It reverses any authority.
DISPLAY
Way to grant authority to issue display commands only.
ANY
Way to grant authority to issue any TDP command except RESOLVE, except
AUTHORIZ.
AUTHORIZ
Way to grant authority to issue any TDP command except RESOLVE,

including AUTHORIZ.
93

AUTHORIZ
Syntax Element
Description
RESOLVE
Way to grant authority to issue the DISPLAY and RESOLVE TDP commands.
Usage Notes
At the start, the system is set to the default authority level of NONE.
You can execute the AUTHORIZ command from:
Location
When
TDPPARM data set
During TDP initialization
System operator console
After TDP initialization
A command interface user with AUTHORIZ

authority
After TDP initialization
Example 1
AU ALL DISPLAY
94

COMMENT
COMMENT
Purpose
Adds comments to the JOBLOG and GTF, if being used.
Syntax
COMMENT
COM
text
FZAPZ001
where:
Syntax Element
Description
text
A comment consisting of all characters until the end of the command
Usage Notes
If the comment is to be written to GTF, the USR GTF option must be specified both when
GTF is started and when the trace records are formatted. The GTF JOBNAMEP option might
also to warranted to limit tracing of user records to the desired TDP
Example 1
COMMENT Begin performance test 6
Completion Message
TDP2062 "COMMENT" COMMAND COMPLETE
95

COMMIT
COMMIT
Purpose
Commits a single 2PC in-doubt session or all 2PC in-doubt sessions for a specified
coordinator.
Syntax
COMMIT
COMMI
ALL
SESSION
COORD
name
number
HOST id
FZAPA003
where:
Syntax Element
Description
ALL
Specifies that all in-doubt sessions for the coordinator are to be committed.
SESSION
Specifies that only one session is to be committed.
number
Number of the in-doubt session to be committed.
name
Coordinator name in alphanumeric characters.

In z/OS, the coordinator name is either:
The CICS VTAM application name, or
The IMS system id
id
(Optional) logical host ID, a decimal number.

The default is host ID of the current TDP.
Usage Notes
The COMMIT command includes a LOGOFF action by default. The result of this command
is recorded in the InDoubtResLog on the Teradata Database.
Example 1
COMMIT ALL COORD IMS
Completion Message
TDP0419 ALL IN-DOUBT SESSIONS FOR COORDINATOR IMS COMMITTED
Example 1
COMMIT SESSION 4321 COORD CICSS2
Completion Message
TDP0402 SESSION 4321 COMMITTED
96

DETACH CP
DETACH CP
Purpose
Deallocates a specific channel device from the operating system.
Syntax
DETACH
DET
cpname
2416A011
where:
Syntax Element
Description
cpname

the device number of the even-numbered device. Either three or four
Usage NotesThe DETACH IFP command can only be used when the CP is STOPped or
has never been STARTed.
The devices can be dynamically or explicitly allocated by the ATTACH commands. If they
were dynamically allocated they will be dynamically de-allocated. If they were explicitly
allocated, TDP will not longer use them but they will remain allocated: TDP must be
shutdown to deallocate them.
Example
DETACH CPC308
Completion Message
TDP1363 DETACH COMMAND ACCEPTED FOR CPC308
TDP1357 "CPC308" HAS BEEN DETACHED
97

DETACH IFP (Deprecated by the DETACH CP command)
DETACH IFP (Deprecated by the DETACH CP

command)
Purpose
Deallocates a CP from a TDP.
Syntax
DETACH
DET
cpname
2416A011
where:
Syntax Element
Description
cpname

device, in three or four hexadecimal digits.
Usage Notes
If the devices were dynamically allocated by the ATTACH or START commands, they are deallocated.
The DETACH IFP command is successful only if the CP identified is currently attached to
TDP and the CP is stopped.
The CP is considered stopped if the CP was never started, or if a STOP CP operator command
was successfully processed for the CP.
Example
DET IFP490
Completion Message
TDP1357 IFP490 DETACHED
98

DISABLE IRF
DISABLE IRF
Purpose
Disables TDP internal sessions that are used for 2PC in-doubt resolution.
Syntax
DISABLE
DISA
IRF
FZAPB005
Usage Notes
This command disables the In-doubt Resolution Facility (IRF), which consists of two
TDP-internal sessions used for 2PC in-doubt resolution. The result of the DISABLE IRF
command is that the two TDP-internal sessions are logged off from the Teradata Database.
If there are no other sessions logged on and the DISABLE IRF command is completed, the
status display on the RDBMS console changes to LOGON/QUIET. This LOGON/QUIET state
is necessary for the Reconfiguration program to be run.
Use the DISABLE IRF command to log off the internal sessions, which have the jobname of
*TDPINT*. After executing the Reconfiguration program, use the ENABLE IRF command to
re-establish the two internal sessions.
If IRF is disabled, then automatic in-doubt resolution and the TDP commands for manual
in-doubt resolution (COMMIT, ROLLBACK, and DISPLAY INDOUBT) are rejected. Note
that if IRF is disabled, you are still able to use manual in-doubt resolution if you use a CLIv2
application or the TPCCONS utility.
Note: To disable the two internal sessions, you must use this TDP command, DISABLE IRF.
Do not use the Performance Monitor command, ABORT SESSIONS, to log off TDP internal
sessions.
Example
DISA IRF
Completion Message
TDP0445 sessiontype SESSION ENDED
where sessiontype is either RBM (Resolver Base Module) or LOG. Usually, one message is
displayed for the RBM session and one for the LOG session.
99

DISABLE LGUX
DISABLE LGUX
Purpose
Causes TDP to stop passing logon requests to the User Logon Exit Interface (TDPLGUX). The
command also detaches the LGUX task. This allows a new version of TDPLGUX to be brought
online without having to stop TDP and then restart it.
Syntax
DISABLE
DISA
LGUX
FZAPB006
Usage Notes
The TDPLGUX is enabled when TDP starts. If the DISABLE LGUX command is subsequently
executed, TDP stops passing logon requests to TDPLGUX and deletes the TDPLGUX module
from main memory.
Example
DISA LGUX
Completion Message
TDP0912 TDP LOGON USER EXIT INTERFACE DISABLED
100

DISABLE LOGONS
DISABLE LOGONS
Purpose
Causes TDP to stop accepting logon requests from applications.
Syntax
DISABLE
DISA
LOGONS
FZAPB007
Usage Notes
When TDP starts, logons are not enabled. Logons are enabled during TDP initialization (see
Initializing a TDP on page 70 for more information) using the ENABLE LOGONS operator
command.
If the DISABLE LOGONS command is executed after logons are enabled, a logon request
from an application program is returned to the application with an error message indicating
that logons are currently not allowed. Sessions that are logged on when the DISABLE
LOGONS command is executed are allowed to continue to completion.
Example
DISA LOGONS
Completion Message
TDP0856 LOGONS DISABLED
101

DISABLE POOL
DISABLE POOL
Purpose
Prevents logons to one or more pools.
Syntax
DISABLE
DISA
POOL
ID poolid
ALL
FZAPB008
where:
Syntax Element
Description
poolid
Unique identifier of the pool that is to be disabled.
ALL
Request that all pools be disabled.
Usage Notes
The DISABLE POOL command is used to prevent applications from logging on to pool
sessions. Once a pool is disabled, any application logon request that would normally be
satisfied by a session from the pool is rejected with an error code.
When a pool is disabled, any session that is in use is allowed to run until the using application
logs off. At that time, the session is returned to the pool.
To enable applications to log on to pool sessions, use the ENABLE POOL command.
Example
DISA POOL ID ACTR04
Completion Message
TDP0881 POOL ID: ACTR04 IS NOW DISABLED
102

DISABLE POOL DETAIL
DISABLE POOL DETAIL

Purpose
Stops TDP from producing a message when a session is not satisfied from a session pool.
Syntax
DISABLE
DIS
POOL
DETAIL
DET
ID poolid
ALL
FZAJCM04
Usage Notes
When TDP is started, POOL DETAIL is disabled. To subsequently enable POOL DETAIL, use
the ENABLE POOL DETAIL command. The current setting can be displayed using the
DISPLAY TDP command.
Example
DISABLE POOL DETAIL
Completion Message
TDP0401 POOL DETAIL HAS BEEN DISABLED
103

DISABLE POOL STATUS
DISABLE POOL STATUS

Purpose
Stops TDP from producing a message when a session is satisfied from a session pool.
Syntax
DISABLE
DISA
POOL
STATUS
STA
ID poolid
ALL
FZAJCM01
Usage Notes
When TDP is started, POOL STATUS is disabled. To subsequently enable POOL STATUS, use
the ENABLE POOL STATUS command. The current setting can be displayed using the
DISPLAY TDP command
Example
DISABLE POOL STATUS
Completion Message
TDP0401 POOL STATUS HAS BEEN DISABLED
104

DISABLE SECLOGON
DISABLE SECLOGON
Purpose
Disables the security logon function that provides an interface to the System Authorization
Facility (SAF) on z/OS client systems.
Syntax
DISABLE
DISA
SECLOGON
FZAPA093
Usage Notes
TDP responds to the DISABLE SECLOGON command with a TDP2108 message indicating
the new status of the security logon function and its messages option.
Example
DISABLE SECLOGON
Completion Message
TDP2108 SECLOGON: DISABLED, DIAGNOSTIC MSGS: DISABLED
105


Purpose
Stops TDP from producing messages when a session ends that indicate the elapsed time that
the session spent within the application and within the Teradata Database.
Syntax
DISABLE
DISA
SESSION
DETAIL
DET
FZAPA096
Usage Notes
When TDP starts, Session Detail is disabled. To subsequently enable Session Detail, use the
ENABLE SESSION DETAIL command. The current setting can be displayed using the
When Session Detail is enabled and a session ends, a TDP0846 message is produced to
indicate the total elapsed time that the session spent within the application and within the
Teradata Database.
Example
Completion Message
TDP0401 SESSION DETAIL HAS BEEN DISABLED
106


Purpose
Causes TDP to release the reserved session capacity so that customer applications can use the
maximum session capacity supported by the Teradata Database.
Syntax
DISABLE
DISA
SESSION
RESERVE
RES
FZAPB009
Usage Notes
When TDP starts, the Session Reserve is enabled. To subsequently disable Session Reserve, use
the DISABLE SESSION RESERVE command.
When Session Reserve is enabled and more than one SP is operational, TDP reserves a number
of sessions equal to the capacity of one SP. This is to ensure that if a single SP fails, all user
sessions allocated to the failed SP can be switched to other SPs that were started by this TDP.
This command affects the value of DBC/1012 MAXSESS, as displayed in the output from the
DISPLAY TDP command. This is a separate limit from the value of TDP MAXSESS, which is
controlled by the SET MAXSESS command. The maximum number of sessions that can be
logged on through this TDP is the lower of these two values.
When the maximum number of sessions is already logged on to TDP, any new logon request
from an application is refused with an error code of CLI0513.
Example
DISA SESSION RES
Completion Message
TDP0401 SESSION RESERVE HAS BEEN DISABLED
107


Purpose
Stops TDP from producing a message when a session starts or ends.
Syntax
DISABLE
DISA
SESSION
STATUS
STA
FZAPA097
Usage Notes
When TDP starts, Session Status is disabled. To subsequently enable Session Status, use the
ENABLE SESSION STATUS command. The current setting can be displayed using the
If Session Status is enabled, a TDP0899 message is produced when a session starts, and a
TDP0898 message is produced when a session ends. When a session to be used for session
pool assignment is started, a TDP0800 message is produced; when such a session ends, a
TDP0801 message is produced.
These messages had previously been controlled by the ENABLE TEST command. For
compatibility, they continue under TEST control until an ENABLE SESSION STATUS or
DISABLE SESSION STATUS is issued, after which TEST has no effect on these messages.
Example
Completion Message
TDP0401 SESSION STATUS HAS BEEN DISABLED
108

DISABLE SMF
DISABLE SMF
Purpose
Prevents all System Management Facility (SMF) records from being recorded. The recording
of specific subtypes of SMF records can also be disabled.
In VOS3, applies to SMS records.
Syntax
DISABLE
DISA
SMF
ALL
SUBn
FZAPB010
where:
Syntax Element.
Is the specification that recording for . . .
ALL
all SMF record types is to be disabled.
SUBn
certain SMF types is to be disabled

Available subtypes are as follows:
1: Session Termination
2: Security Violation
3: CP Activity
4: TDP Shutdown
5: Structure-protocol termination
Usage Notes
When TDP starts, SMF recording is enabled for subtypes 1 through 4. To disable SMF
recording, use the DISABLE SMF command.
The ALL argument is the default for this command. Entering just the DISABLE SMF
command with no arguments, disables recording for all SMF record subtypes.
To disable the recording of a specific SMF record subtype, use the SUBn argument, where n is
the number of the SMF record type to have its recording disabled.
109

DISABLE SMF
Example 1
DISA SMF
Example 2
DISA SMF SUB1
Completion Message
TDP0594 SMF RECORDING DISABLED
110

DISABLE TDPSTATS
DISABLE TDPSTATS
Purpose
Causes TDP to discontinue collection of statistical and performance information.
Syntax
DISABLE
TDPSTATS
DISA
FE0CA043
Usage Notes
When TDP starts, TDPSTATS is not enabled. TDPSTATS is enabled by executing the ENABLE
TDPSTATS command. Use the DISPLAY TDPSTATS command to display the current status
of TDPSTATS.
Example
DISA TDPSTATS
Completion Message
TDP2501 TDP THROUGHPUT STATISTICS REPORTER DISABLED
111

DISABLE TEST
DISABLE TEST
Purpose
Causes TDP to discontinue writing informational or diagnostic messages to the system
console.
Syntax
DISABLE
DISA
TEST
FZAPB011
Usage Notes
When TDP starts, TEST mode is not enabled. TEST can be enabled by executing the ENABLE
TEST operator command.
If the DISABLE TEST command is executed after TEST is enabled, informational messages
produced by TEST mode are no longer written to the system console.
Example
DISA TEST
Completion Message
TDP0542 TEST MODE DISABLED
112

DISABLE TIME
DISABLE TIME
Purpose
Prevents TDP from sending time to the Teradata Database.
Syntax
DISABLE
DISA
TIME
TIM
FZAPB012
Usage Notes
If neither an ENABLE TIME nor a DISABLE TIME command is issued, the default action is
specified in the HSISPB. While the HSISPB can be customized as necessary, as distributed,
DISABLE TIME is the default. You can use the ENABLE TIME command to enable the option
again.
If you are using a Teradata Database release between V1R4.1 and V1R5.1, inclusive, the
ENABLE TIME feature is supported only for DBC/1012 configurations controlled by a Model
2 Access Module Processor (AMP) or below. If the configuration at your site does not include
a Model 2 AMP, you can include the DISABLE TIME command in the TDPPARM data set to
reduce meaningless channel traffic.
For releases prior to V1R4.1 or V1R5.2 and above, ENABLE or DISABLE TIME function as
expected.
To set the time, use the RDBMS console command, SET TIME.
Example
DISA TIM
Completion Message
TDP0596 HOST TO DBC TIME MESSAGES ARE: DISABLED
113

DISABLE TMON
DISABLE TMON
Purpose
Disables TDP calls to the User Transaction Collection Exit (TDPUTCE) routine, which is used
to collect statistics about requests and responses that traverse TDP.
Syntax
DISABLE
DISA
TMON
FZAPB013
Usage Notes
When TDP starts, the TDPUTCE is enabled. If the DISABLE TMON command is
subsequently executed, TDP stops passing requests and responses to TDPUTCE and deletes
the TDPUTCE module from main memory.
Example
DISA TMON
Completion Message
TDP0922 TDP USER MONITOR EXIT INTERFACE DISABLED
114

DISABLE TRAP
DISABLE TRAP
Purpose
Disables a previously-enabled diagnostic trap.
Syntax
DISABLE TRAP NAME name
FE0CA050
DISA
where:
Syntax Element.
Description
name
Name of a previously-established trap
Usage Notes
A trap is established by the ENABLE TRAP command.
DISABLE TRAP is intended for use in consultation with Teradata Customer Support
personnel.
Example
DISABLE TRAP NAME TRAP0001
Completion Message
TDP0401 TRAP TRAP0001 HAS BEEN DISABLED
115

DISABLE UAX
DISABLE UAX
Purpose
Causes TDP to stop passing requests to the User Address Space Exit Interface (TDPUAX).
Syntax
DISABLE
DISA
UAX
FZAPB014
Usage Notes
The TDPUAX is available only in the z/OS or VOS3 environment.
The TDPUAX is enabled by the ENABLE UAX command.
Example
DISA UAX
Completion Message
TDP0597 TDP USER ADDRESS SPACE EXIT INTERFACE NOW DISABLED
116

DISABLE USEC
DISABLE USEC
Purpose
Causes TDP to stop passing security and logon violations information detected by the
Teradata Database and by the User Logon Exit Interface (TDPLGUX) to the TDP User
Security Interface (TDPUSEC). The command also detaches the TDPUSEC task. This allows a
new version of TDPUSEC to be brought on-line without having to stop TDP and then restart
it.
Syntax
DISABLE
DISA
USEC
FZAPB015
Usage Notes
When TDP starts, the TDPUSEC is enabled. If the DISABLE USEC command is subsequently
executed, TDP stops passing security and logon violations information to the TDPUSEC and
deletes the TDPUSEC module from main memory.
Example
DISA USEC
Completion Message
TDP0902 TDP USER SECURITY EXIT INTERFACE DISABLED
117

DISPLAY CCU
DISPLAY CCU
Purpose
Displays limits used during operation of CCU-type CPs.
Syntax
DISPLAY
CCU
FE0CB046
Note: The DI and DIS abbreviations are deprecated.

Usage Notes
The maximum number of channel blocks for an I/O, the maximum size of a channel block,
and the number of checksum rejections at which the CP will become unusable are displayed.
The values can be set using the INITIAL CCU MAXBLKNM, INITIAL CCU MAXBLKSZ, and
INITIAL CCU MAXCKSUM commands.
Example
DISPLAY CCU
118

DISPLAY CELLS
DISPLAY CELLS
Purpose
Displays cell availability and usage information generated by the TDP internal memory
management system. The information is accumulated from the time the current TDP was
started; there is no command to reset it.
Syntax
DISPLAY
D
CELLS
CEL
VERIFY
VER
FZAP B016

where:
Syntax Element
Description
VERIFY
Specification that the actual number of z/OS PC cells that are currently in use
is to be displayed.
This option is intended for use in consultation with Teradata support
personnel. Use of this option normally has no effect on the accuracy of the
information and simply increases system overhead.
Usage Notes
When TDP is started, the following number of each cell size is obtained.
Cell Size
Number of Cells
64 bytes
500
128 bytes
500
240 bytes
150
256 bytes
500
352 bytes
500
416 bytes
500
992 bytes
500
When IACMODE PC is specified, the following number of each XMS cell size is obtained.
119

DISPLAY CELLS
Cell Size
Number of Cells
256 bytes
200
416 bytes
200
992 bytes
390
Each time TDP is started, the number of cells can be increased using the TDPADD CELLS,
ADD XMSCELLS, and INITIAL IOBUFS commands in the TDPPARM dataset. While TDP is
running the number of cells can be increased using the TDP ADD CELLS and ADD
XMSCELLS commands. There is no way to reduce the number of cells.
When you execute the DISPLAY CELLS command, TDP displays the following information
about cells in the memory management system:
Column
Description
CELSZ
Size, in bytes, of a cell.
AVAIL
Number of cells not currently in use.
INUSE
Number of cells currently in use.
MXUSE
Maximum number of cells used at any one time. This will include any cells
reserved for IOMODE PC interface usage.
GMAIN
Number of times a cell was dynamically obtained.

Normally, if no cell is available the TDP process will be suspended until a cell
is made available, but under certain circumstances a cell will be dynamically
obtained to satisfy the request. A cell dynamically obtained is freed when no
longer in use. PC cells are never dynamically obtained. Overall throughput
can be impacted since dynamically obtaining a cell is less efficient that reusing
an available cell. The larger the number of dynamic actions, the greater the
potential performance impact.
PC
Number of cells reserved for use by the IOMODE PC interface at any one
time.
#WAITS
Number of times a TDP process was suspended because no cells were

available.
Normally, if no cell is available the TDP process will be suspended until a cell
becomes available. Overall throughput can be impacted since a suspended
TDP process is not available to process other work. The larger the number of
suspensions, the greater the potential performance impact
If INITIAL IACMODE PC is specified, information about cross-memory cell shortages is also

displayed. That information could be:
120
TDP1250, which indicates the number of times that at least one of the three cross-memory
cell pools was exhausted. Each request requires one cell from each of the three crossmemory cell sizes. If any of the sizes is unavailable, the request must wait.

DISPLAY CELLS
TDP1251, which indicates the number of times that no cell was available to process a
request that required more than one cell from the largest cross-memory cell pool
Except for a small number of cells used for specialized purposes, all cells are allocated from
31bit storage
If all available cells of a given size are used at one time, the following message is issued:
TDP0021 **WARNING** 100% of <size> BYTE CELLS IN USE
Such a message appears at most once for each cell size.

Example
D CEL
Completion Message
The result of the DISPLAY CELLS command is in the following format:
TDP0501
TDP0528
TDP0528
TDP0528
TDP0528
TDP0528
TDP0528
TDP0528
TDP0528
TDP0528
TDP0529
TDP1250
TDP1251
TDP0500
CELSZ AVAIL INUSE MXUSE

GMAIN PC
#WAITS
00064 00498 00002 00042 0000000 00000 00000
00128 00496 00004 00006 0000000 00000 00000
00240 00499 00001 00043 0000000 00000 00000
00256 00491 00209 00247 0000000 00200 00000
00352 00497 00006 00006 0000000 00000 00000
00416 00497 00203 00204 0000000 00390 00000
00480 00005 00001 00005 0000000 00000 00000
00992 00498 00392 00890 0000000 00390 5265*
12272 00004 00002 00006 0000000 00000 12272*
OVERSIZE CELLS, INUSE: 1 MAXUSE: 0 GETMAINS: 1
WAITS FOR INITIAL PC CELLS: 0
WAITS FOR ADDITIONAL PC CELLS: 0
ADDITIONAL I/O CONTROL BLOCKS OBTAINED: 0
Notes on the Example

TDP1250 and TDP1251 appear only if IACMODE PC is specified.
TDP0500 appears only if TEST is enabled, IOMODE IOSDRIVR is specified, and CIC-type
CPs are being used. Note that the I/O Control Blocks mentioned are not IOBUFS.
The #WAITS entry that contains an asterisk to the right of the five-digit number (00001*)
indicates that TDP is currently waiting for the 12,272 byte cell size.
The #WAITS entry that contains an asterisk in the last position of the five-digit number
(5625*) indicates that the #WAITS counter has wrapped (that is, it is a very large number).
121

DISPLAY CHECKSUM
DISPLAY CHECKSUM
Purpose
Displays the status of checksum validation of data transfers to and from the Teradata Database
when using CCU-type CPs.
Syntax
DISPLAY
D
CHECKSUM
CHE
EF03A072

Usage Notes
Use the SET CHECKSUM command to change the CHECKSUM setting.
Message
TDP2036 CHECKSUM IS AUTOMATIC BY CP
122

DISPLAY CP
DISPLAY CP
Purpose
Displays the status of channel processors (CPs) that are assigned to this TDP.
Syntax
DISPLAY
D
CP
A
PNUM
xxxx
REQUESTS
NAME cpname
NODETAIL
DETAIL
A
LOCATION
PROTOCOL
SELECT
2416A001

where:
Syntax Element
Description
xxxx
A four-character hexadecimal CP id for which information is to be displayed.

If neither NAME nor PNUM is specified, information for all CPs is displayed.
cpname
A six or seven character CP name for which information is to be displayed. The

name is that which had been specified on a previous TDP START
CPcommand.
If neither NAME nor PNUM is specified, information for all CPs is displayed.
REQUESTS
Indicates that a list of all pending and active requests for the CP is to be
displayed.
NODETAIL
Indicates that no diagnostic information for the CP is to be displayed. This is

the default.
DETAIL
Indicates that diagnostic information for the CP is to be displayed.

This option is intended for use in consultation with Teradata customer
support personnel.
Note: The associated information requires internal knowledge of TDP to
properly interpret. Without such knowledge, misleading conclusions are
probable. Time can be saved by heeding this recommendation.
123

DISPLAY CP
Syntax Element
Description
LOCATION
Indicates that diagnostic information concerning the location of the CP within

the Teradata Database is to be displayed. If such information is not available,
nothing is added to the display.
support personnel.
PROTOCOL
Indicates that diagnostic information for the communication protocol being

used by the CP is to be displayed.
support personnel.
SELECT
Indicates that diagnostic information for the selection of the CP for sending
requests is to be displayed.
support personnel.
CHECKSUM
Indicates that the status of checksum in effect for a CCU-type CP is to be

displayed. Use the SET CHECKSUM command to control the use of
checksum.
Usage Notes
The following information is always displayed, as applicable:
124
CP name
Current TDP command status for the CP, as either DETACHED, STOPPED. STARTED or
HALTED. The first three correspond to normal TDP CP commands; HALT is a command
TDP issues internally. If the command has not completed, then DETACHING,
STOPPING. STARTING or HALTING will be displayed followed by the requested final
state as DETACHED, STOPPED. STARTED or HALTED.
Any special TDP conditions as follows:

Condition
Description
ENDING
Use of the CP is ending.
TEMP-ERROR
CP transmission is being retried.
IPERM-ERROR
CP transmission has failed.

DISPLAY CP
If the communication status of the CP is not normal, the CPnumber and that status as
follows:
Status
Definition
NOT OPERATIONAL
Communication with the Teradata Database is not established.
OPERATIONAL
Communication with the Teradata Database has been established.
INITING
Operational but the communication protocol between TDP and the

device is being initialized.
SYNCING
Operational but the status of TDP has not yet been synchronized
with that of the Teradata Database.
QUIESCED
Operational but the number of consecutive requests sent to the

Database on the CP without receiving any responses exceeded the
value indicated by the DISPLAY LIMIT NORESP command.
The number of active or pending requests.
If quiesced because the number of consecutive requests sent to the Database on the CP
without receiving any responses exceeded the limit indicated by the DISPLAY LIMIT
NORESP command, this limit is displayed.
Diagnostic Options
The following information is meaningful when consulting with Teradata customer support
personnel; when applicable, it is presented to aid in diagnosis without having to re-create the
problem.
The information displayed varies according to which options, or combination of options are
specified when issuing the DISPLAY CP command. Each option and the possible resulting
display information is provided.
REQUEST
Request number
Session number
State of the request as follows:

State
Description
ACTIVE
The request has been sent.
PENDING
The request is waiting to be sent.
DETAIL
Issuing the DETAIL option causes a listing of diagnostic information for the CP to be
displayed.
If communication status of the CP is not normal, the following information will be displayed:
125

DISPLAY CP
The CP number
The status (NOT OPERATIONAL, OPERATIONAL, INIT'ING, SYNC'ING, and

QUIESCED) as previously defined.
The number of messages and bytes sent by the output device
The number of messages and bytes received by the input device
The total number of messages and bytes transferred (if appropriate for internal operation)
If meaningful, the following information will be displayed for output and input devices:
The number of I/O buffers associated with any current I/O
The maximum number of buffers used for any one I/O
The number of times an I/O was limited by the maximum number of blocks per I/O
The number of times an I/O was limited by the maximum amount of virtual storage
available for I/O
Note: If information is not meaningful it may not be displayed.

If meaningful, the following additional information will be displayed for output devices:
The number of I/O buffers associated with any I/O being constructed
The number of times a delay was incurred to wait for an I/O buffer
If meaningful, the following additional information will be displayed for input devices:
The number of attempts to obtain an I/O buffer that failed
The number of times a delay was incurred to wait for a TDP 992-byte cell
If there is a current delay waiting for a 992-byte cell
The following information will be displayed for CPs utilizing the CCU operand on the START
command:
The I/O buffer utilization information for each device
The protocol structure that is expected from the Teradata Database (if the communication
protocol is being initialized)
Which CP explicit SP or implicit SP associated with the CP will be used (if the
communication protocol is being synchronized and a Configuration Request is to be sent)
The number of SPs remaining (if the communication protocol is being synchronized and
SPs are being synchronized)
Whether all or only dependent SPs are involved (if the communication protocol is being
synchronized and SPs are being synchronized)
If communication has been lost, the following information will be displayed:
126
A count of how many times such an event has occurred for this CP
The status of the input and output devices as follows:

Status
Description
DOWN
The device has stopped responding.

DISPLAY CP
Status
Description
RECOVERED
A down device has begun responding.
INVOLVED
The device will be recovered but has not yet been

found to be down.
OBLIVIOUS
The device is not affected by the loss of

communication of the other device.
LOCATION
Issuing the LOCATION option causes a listing of diagnostic information concerning the
physical location of the CP within the Teradata Database including:
The cabinet
The processor-id within the cabinet
Note: If the Teradata Database does not supply information about the physical location no
location information is displayed.
PROTOCOL
Issuing the PROTOCOL option causes a listing of diagnostic information about the
communication protocol being used by the CP.
The following information will be displayed for CPs utilizing the CCU operand on the START
command:
Any explicit SP-number and the routing factor
The maximum number of bytes per block
The maximum number of bytes per structure
The type of channel attachment
The following information will be displayed for CPs not requiring the CCU operand:
The maximum number of bytes per block and the Teradata Databases default value
The maximum number of blocks per I/O and the Teradata Databases default value
SELECT
Issuing the SELECT option causes a listing of diagnostic information for the selection of the
CP for sending requests. When appropriate for the current operation the information can
include:
The relative power of the CP to other CPs
The origin of other CPs when this CP was started
CHECKSUM
Issuing the CHECKSUM option causes the status of checksum in effect for a CCU-type CP to
be displayed. The information can include:
The status (ON, OFF or AUTO) of the last SET CHECKSUM command
127

DISPLAY CP
The number of times that the Teradata Database has activated checksum (if the status is
AUTO)
Note: If the status is AUTO, ACTIVE indicates that checksum has been activated by the
Teradata Database and INACTIVE indicates that it has not.
The number of messages sent to the Teradata Database with checksums (if checksums have
been processed)
The number of messages received from the Teradata Database with checksums (if
checksums have been processed)
Example
D CP
Completion Message
TDP1298 "CP0B92" STARTED
TDP1281
ACTIVE REQUESTS: 1, PENDING REQUESTS: 0
TDP1298 "CP0B90" STARTED
128

DISPLAY IFP (Deprecated by the Display CP command)
DISPLAY IFP (Deprecated by the Display CP

command)
Purpose
Displays the status of CPs that are allocated to TDP.
Syntax
DISPLAY
D
IFP
IFPnnnn
STATE
2416A010

where:
Syntax Element
Description
IFP
Specificies that a summary of the desired status of all active CPs be

displayed.
IFPnnnn
CP whose information is to be displayed as IFPnnnn, where nnnn is the device

number of the even-numbered CP device, in three or four hexadecimal digits.
STATE
Option that is used for diagnostic purposes only and should be used in
consultation with Teradata customer support personnel.
Usage Notes
When the DISPLAY IFP form of the command is executed, for each active CP, TDP displays a
summary line containing:
CP name
The desired status of the CP. Normally this reflects the completion of the last command
affecting the CP (STARTED or STOPPED) or that the command is ongoing (STARTING
or STOPPING). If the CP is unavailable on the Teradata Database, HALTED or HALTING
can appear. Other possible states are:
COMM LOST indicates that communication has been lost
SYNCING indicates that communication is being restored
TEMP ERROR indicates that an I/O error occurred
PERM ERROR indicates that the CP is not currently configured on the Teradata
Database
QUIESCED indicates the number of consecutive requests sent to the Database on a CP

without receiving any responses exceeded the value indicated by the DISPLAY LIMIT
NORESP command.
129

DISPLAY IFP (Deprecated by the Display CP command)
When the DISPLAY IFPnnnn form of the command is executed, TDP displays the name and
status of the specified CP, plus the number of blocks, messages, packets, and bytes that the CP
has sent to, and received from, the Teradata Database.
Note that the DISPLAY IFP command displays the desired status, for example, a status that
has been set with the START CP or STOP CP command. It may not reflect the current or
actual status of the CP it reflects only what the CP has been set to.
Example 1
D IFP
Completion Message
TDP0517 IFP490 STARTED
TDP0517 IFP492 STARTED
Example 1
D IFP490
Completion Message
TDP0519 IFP490
BYTES 62052464
TDP0519 STARTED
OUTPUT BLOCKS 29535 MESSAGES
29501 PACKETS 338991
INPUT
29818 PACKETS 29834
BLOCKS 28099 MESSAGES
BYTES 3730779
130

DISPLAY INDOUBT
DISPLAY INDOUBT
Purpose
Displays any 2PC in-doubt sessions or any coordinators that have in-doubt sessions.
Syntax
DISPLAY
D
INDOUBT
IND
SESSIONS COORD name

HOST id
RESOLVED
COORDS
HOST id
FZAPB018

where:
Syntax Element
Description
SESSIONS
Specifies that all currently in-doubt sessions be displayed for a coordinator.
name

The CICS CTAM application name, or
The IMS system id
id
(optional) logical host ID, a decimal number.

The default is the host ID of the current TDP.
RESOLVED
Specifies that the display include sessions that were manually resolved, as well
as sessions that are currently in-doubt, for a coordinator.
The returned session status can be IN-DOUBT, COMMITTED, or ROLLED
BACK.
COORDS
Specifies that all coordinators with in-doubt sessions be displayed.
Example 1
DISPLAY IND COORDS
Completion Message
TDP0410 COORDINATORS WITH IN-DOUBT SESSIONS
coordinator
coordinator
...
where coordinator is the coordinator name.
Example 1
DISPLAY IND SESSIONS COORD IMSA
131

DISPLAY INDOUBT
Completion Message
TDP0412 IN-DOUBT SESSIONS FOR COORDINATOR IMSA
TDP0413
SESSION RUN-UNIT
####### rrrrrrr
...
where:
Syntax Element
Description
#######
Session number.
rrrrrrr
Run-unit id.
Example 1
DISPLAY IND SESSIONS COORD CICSS2 RESOLVED
Completion Message
TDP0409 IN-DOUBT OR RESOLVED SESSIONS FOR COORDINATOR name
TDP0437
STATUS
SESSION
RUN-UNIT
TDP0438
sssssssssss ########### rrrrrrrrrrr
...
where:
132
Syntax Element
Description
sssssssssss
Phrase, IN-DOUBT, COMMITTED, or ROLLED BACK.
###########
Session number.
rrrrrrrrrrr
Run-unit id.

DISPLAY JOB
DISPLAY JOB
Purpose
Displays detailed information on jobs that are communicating with the Teradata Database
through TDP. The DISPLAY JOB command requires a valid job name as an operand. Note
that in some cases the job name is a userid.
To use this command, you must first use the DISPLAY SESSIONS command to display a list of
current jobs, then use a listed jobname as the operand to the DISPLAY JOB command.
Syntax
DISPLAY
D
JOB jobname
FZAPB019

where:
Syntax Element
Description
jobname
Name of job for which status information is to be displayed.
Usage Notes
When the DISPLAY JOB command is executed, TDP displays:
Job name
Number of sessions owned by the job
Status of logons (enabled or disabled) for the job
Status of each session owned by a job:
Name of the job owning the session
Session number (in decimal numbers)
Status of the session

One of the following is always present:
Status
Description
IDLE
Session has no request active.
ACTIVE
Session has a request active
133

DISPLAY JOB
One or more of the following can be present if the condition occurs:

Status
Description
STARTING
Session has not completed logon processing.
ENDING
Session has not completed logoff processing.
SWITCH PENDING
Session must be switched to another session processor, which is

not yet assigned.
SWITCH ACTIVE
Session is currently being switched to a new session processor.
Example
D JOB BASE7MA
Completion Message
TDP0524 JOB BASE7MA, 1 SESSIONS, 1 ACTIVE,
LOGONS ENABLED
TDP0525 JOB BASE7MA, SESSION 1012: ACTIVE
134

DISPLAY LIMIT
DISPLAY LIMIT
Purpose
Displays information related to TDP limits established by the TDP SET LIMIT command.
Syntax
DISPLAY
LIMIT
LIM
NORESP
NOR
JCM03230601
Usage Notes
If NORESP is not specified, it is assumed.
For NORESP, the following information is displayed: the number of consecutive requests that
can sent to the Database on a CP without receiving any responses before TDP will consider
that CP as unresponsive (that is, the value established by the SET LIMIT command), the
highest such value currently reached for any CP, and the highest such value reached by any CP
since TDP was started.
Example
DISPLAY LIMIT
135

DISPLAY MODULE
DISPLAY MODULE
Purpose
Displays information about a TDP module.
Syntax
DISPLAY
D
MODULE name
LOCATION
FZAPB092

where:
Syntax Element
Description
name
name of a TDP module.
LOCATION
optional request that displays the storage location and length of the module,
Usage Notes
Since the names of the TDP modules and the interpretation of the resulting information
requires understanding of the internal structure of TDP, this command is intended for use in
consultation with Teradata customer support people.
The earlier, undocumented form of the command, DISPLAY HISTORY, is a synonym for the
DISPLAY MODULE command.
Example
D MODULE TDPSYNC
Completion Message
TDP2000 TDPNSPCI: 06.00.00.00 (08/15/96 AT 10:01)
136

DISPLAY POOL
DISPLAY POOL
Purpose
Lists information and statistics about one or more established session pools.
Syntax
DISPLAY
D
POOL
ALL
ID poolid
FZAPB020

where:
Syntax Element
Description
poolid
Id of pool whose information is to be displayed.
ALL
Request that information about all pools be displayed.
Usage Notes
If an error occurs during START POOL processing (because creation of further pool sessions
will cause Teradata Database or installation-defined maximum session capacity (MAXSESS)
to be exceeded), you can use the DISPLAY POOL command to determine how many sessions
were successfully added to the pool before the error prevented further processing. Later, if
session demand is reduced, you can use the MODIFY SESSIONS command to acquire the
desired number of sessions for the pool.
Example
D POOL ID ACTR04
D POOL ALL
Completion Message
The completion message to the DISPLAY POOL command consists of a header line, followed
by one line of statistics per pool, as follows:
ID
poolid
REQD AVAL ALC BUSY LOGS ERR E/D

(statistics appear under these headings)
137

DISPLAY POOL
where:
138
Column heading . . .
Contains the . . .
ID
unique identifiers of the pool whose statistics are displayed.
REQD
number of sessions requested for the pool in the START POOL or MODIFY
POOL command.
AVAL
number of sessions in the pool that are currently not in use and available to
satisfy application logon requests.
ALC
number of pool sessions that are currently in use by applications.
BUSY
number of pool sessions that are in the process of logging on to the Teradata
Database.
LOGS
number of application logon requests that have already been satisfied by pool
sessions.
ERR
number of application logon requests that have been denied owing to a lack
of available pool sessions.
E/D
indication of whether logons to the pool are enabled (E), or disabled (D).

DISPLAY QUEUES
DISPLAY QUEUES
Purpose
Displays the status of internal work queues for a TDP.
Syntax
DISPLAY
D
QUEUES
Q
FZAPB021

Usage Notes
After the DISPLAY QUEUES command is executed, TDP displays a status line containing the
following for each of its internal work queues:
Task name
Number of work elements in the queue for the task
Number of command elements in the queue for the task
Number of other work elements for the task
Tasks are only displayed if they have non-zero counts.

Example
D Q
Completion Message
TDP0554 TASK: TDPWTO, WORK(3), COMMANDS(0), OTHER(0)
TDP0554 TASK: TDPCMD, WORK(1), CMDS(0), OTHER(0)
139

DISPLAY SERVER
DISPLAY SERVER
Purpose
Displays attributes of the Teradata Database with which TDP is communicating.
Syntax
DISPLAY SERVER
D
FEATURES
CHARSETS
KY01A123

where:
Syntax Element
Description
FEATURES
Indicates that a list of all internal Teradata Database features provided to TDP
is to be displayed.
CHARSETS
Indicates that a list of all character sets supported by the Teradata Database is
to be displayed.
Usage Notes
The following information is always displayed:
The decimal id of the logical host
The default character set (a question mark is substituted if for some reason the name
cannot be ascertained)
The default transaction semantics
The numeric parallelism factor
The numeric values for the maximum segment number and maximum segment size.
The following information may be displayed, depending on the options specified in the
command:
140
FEATURES, which is a list of names of the feature information. The usefulness of this
information depends upon knowledge of TDP internals; it is intended for use in
consultation with Teradata customer support personnel.
CHARSETS, which is the character set name and corresponding numeric code for each
character set

DISPLAY SERVER
Example
DISPLAY SERVER
Completion Message
TDP2040
TDP2041
TDP2042
TDP2043
TDP2044
SERVER INFORMATION
HOSTID: 250, DEFAULT CHARSET: EBCDIC
DEFAULT TRANSACTION SEMANTICS: T
PARALLELISM FACTOR: 8
SEGMENT MAXIMUMS: NUMBER(0), SIZE(0)
141

DISPLAY SESSIONS
DISPLAY SESSIONS
Purpose
Displays the status of sessions that are communicating with the Teradata Database through
TDP.
Syntax
DISPLAY
D
SESSIONS
SES
ALL
sessnumber
NODETAIL
DETAIL
ENDING
NODETAIL
DETAIL
2416A002
Note: The DI and DIS abbreviations for DISPLAY, AL for ALL, and EN for ENDING are
deprecated.
where:
Syntax Element
Description
sessnumber
Decimal session number for which status information is to be displayed.

Leading zeros need not be specified.
ENDING
Specifies that status information be displayed only for sessions that are ending.
(An ending session is one for which a logoff request has been sent to the
Teradata Database but not yet acknowledged.)
ALL
Specifies that status information be displayed for all sessions.

This is the default if no operand is chosen.
NODETAIL
Indicates that no diagnostic information for the session is to be displayed. This

is the default.
DETAIL
Indicates that diagnostic information for the session is to be displayed.
Usage Notes
The DISPLAY SESSIONS command can be used to display summary information about jobs
and sessions or detailed information using the operands.
When the DISPLAY SESSIONS command is executed with the default ALL operand, TDP
displays the following:
142
Number of sessions logged on to TDP
Number of sessions that are ending

DISPLAY SESSIONS
Status of logons to TDP (enabled or disabled)
Job names and the status of their sessions
Number of sessions
Number of active sessions
Status of the session:

One of the following is always present:
Status
Description
IDLE
Session has no request active.
ACTIVE
Session has a request active.
One or more of the following can be present if the condition occurs:

Status
Description
STARTING
Session has not completed logon processing.
ENDING
Session has not completed logoff processing.
SWITCH
PENDING
Session must be switched to another SP, which is not yet assigned.
SWITCH ACTIVE
Session is currently being switched to a new SP.
The listed job names can be used in the DISPLAY JOBS command to display detailed
information about the jobs, including the session numbers related to the different jobs.
Note that the job name *TDPINT* may appear in the result of the DISPLAY SESSIONS
command. This indicates a TDP-internal session (a session owned by TDP itself). There are
two kinds of TDP-internal sessions, and both types have the job name *TDPINT*:
Unallocated POOL sessions
Two TDP-internal sessions that are used for 2PC in-doubt resolution
When the DISPLAY SESSIONS command is executed with the sessnumber or ENDING
operand, TDP displays:
Name of the job owning the session (if the session has not completed logoff processing,
'ENDING' appears)
Session number (in decimal)
Status of the session
If the DETAIL operand is specified (or TEST is enabled and NODETAIL was not specified),
the following information is also displayed:
The function number that identifies the last request:
143

DISPLAY SESSIONS
144
Function Number
Meaning
Logon
Logoff
Run
Logoff all
Logoff all tasks
Connect
DISABLE logons
ENABLE logons
10
Start request
11
Continue request
12
Continue-Data
13
Abort-Data
14
Aborted start request
20
Directed request
Information about the session (note that more than one bit can be set to on in the flag
byte):
Number
Meaning
01
SP switch in progress
02
SP switch required
04
Transaction state unknown
08
Logging off session
10
Request complete
20
Request active on the Teradata Database
40
Request on flow queue
80
Request active in TDP
A state indicator for the session (note that more than one bit can be set to on in the flag
byte):

DISPLAY SESSIONS
State Indicator
Meaning
01
Cleanup required
02
Real pool logoff
04
Pool session
08
Session is owned
10
Abort has been sent
20
Session within user transaction
80
RUN has been performed
Total transaction count
Request number of the last request (in decimal)
SP number
CP number used to send the request to the Teradata Database (if a request is active)
Number of bytes of information sent to the Teradata Database
Number of bytes of information received from the Teradata Database
Session timing
Elapsed time (hhh:mm:ss.t) since the start of the session
Percentage of time (nn:nn:nn%) the session spent in TDP, the Teradata Database, and
waiting for the request from the user application (TDP:DBC:OUT)
Elapsed time (hhh:mm:ss.t) in the specified session state (IDLE or ACTIVE)
Example 1
D SES
Completion Message
TDP0523 2 SESSIONS, 0 ENDING, LOGONS ENABLED
TDP0524 JOB BASE7MA, 1 SESSIONS, 1 ACTIVE, LOGONS
ENABLED
TDP0524 JOB DC, 1 SESSIONS, 0 ACTIVE, LOGONS ENABLED
Example 2
D SES 1012
145

DISPLAY SESSIONS
Completion Message
The following result format is displayed for a specified session number when TDP is in test
mode.
TDP0525
TDP0549
TDP0503
TDP0515
TDP0574
TDP0578
146
JOB BASE7MA, SESSION 1012: IDLE

FUNCT: 10, INFO: 00, STATE: 88 COUNT: 4
REQUEST: 850476, SPNUM: 000F, CPNUM: 000E
BYTES SENT 311, BYTES RECVD: 1582
SESSION ELAPSED: 004:34:45.5
TDP:DBC:OUT=0:0:100%
CURRENT ELAPSED: 004:31:10.8

DISPLAY SMF
DISPLAY SMF
Purpose
Displays the status of TDP System Management Facility (SMF) recording. It displays whether
SMF recording is enabled or disabled and (if necessary) the status of individual SMF record
subtypes.
In VOS3, applies to SMS records.
Syntax
SMF
DISPLAY
D
FZAPB023

Usage Notes
SMF recording can be enabled or disabled for all SMF subtype records or for selected records.
If SMF recording is disabled for only some records, the DISPLAY SMF command shows which
records have that status. There are four record subtypes:
Record
Subtype
Description
Teradata Database session termination record
Teradata Database session security violation record
CPactivity data record
TDP global statistics record (written at time of TDP SHUTDOWN)
Structure-protocol termination record
Example
D SMF
Completion Message
TDP0594 SMF RECORDING ENABLED CONDITIONALLY
TDP0595
SUBTYPE2: DISABLED
TDP0595
SUBTYPE4: DISABLED
147

DISPLAY SP
DISPLAY SP
Purpose
Displays the status of session processors (SPs) that are assigned to this TDP.
Syntax
DISPLAY
D
SP
PNUM
xxxx
SESSIONS
NODETAIL
DETAIL
2416A003

where:
Syntax Element
Description
xxxx
A four-character hexadecimal SP id for which information is to be displayed.

If omitted, all information for all SPs is displayed.
SESSIONS
Indicates that a list of all sessions for the SP is to be displayed.
NODETAIL
Indicates that no diagnostic information for the CP is to be displayed. This is

the default.
DETAIL
Indicates that diagnostic information for the SP is to be displayed.

support personnel.
Usage Notes
The following information is always displayed, as applicable:
148
SP number.
SP Status, as follows:
Status
Definition
NOT OPERATIONAL
The Teradata Database indicates that the SP is down.
OPERATIONAL
The Teradata Database indicates that the SP is up.
USABLE
Operational and the TDP state has been synchronized with that of
the Teradata Database.

DISPLAY SP
Status
Definition
DELAYED
Operational but requests are being delayed while synchronization is

in progress for this SP.
SERIALIZED
Operational and in use for a synchronization request for an SP.
If sessions are allocated:
The total number of sessions
The number of these sessions that are using the Monitor partition
The number of these sessions that are in-doubt but whose original application is no
longer using the session
If any allocated sessions are waiting the response to a Logoff.
If any allocated sessions are involved in switching sessions from a down SP to an

operational SP.
The following information is displayed, according to the options specified in the command:
IF you select
this option . . .
DETAIL
SESSIONS
THEN this information is displayed . . .

IF . . .
This information is displayed . . .
synchronization is in
progress,
whether a Host Start or Session Information

request has been sent and which SP is being used.
this SP has an affinity for

CP,
the extended affinity id and a list of CPs.
this SP is dependent
upon a CP,
the intended dependency id and a list of CPs.
For each session allocated on this SP, the session number, job name and state, as
follows:
State
Definition
IDLE
No request is active.
ACTIVE
A request is active.
STARTING
The session is being established.
ENDING
The session is to be logged off.
SWITCH PENDING
The session is to be switched to an operational SP.
SWITCH ACTIVE
The session is being switched to an operational

SP.
149

DISPLAY SP
IF you select
this option . . .
THEN this information is displayed . . .

Session number for each in-doubt session whose application is no longer using
the session.
Example
D SP
Completion Message
TDP1260 SPNUM 000F: OPERATIONAL, USABLE
TDP1261
SESSIONS: 2 (MONITOR: 0, INDOUBT: 1)
TDP1260 SPNUM 000E: OPERATIONAL, USABLE
TDP1261
SESSIONS: 2 (MONITOR: 0, INDOUBT: 0)
150

DISPLAY STORAGE
DISPLAY STORAGE
Purpose
Displays information about the use of virtual storage by TDP.
Syntax
DISPLAY STORAGE
D
CP
FE0CA047

Usage Notes
If CP is not specified, it is assumed.
For CP, the following virtual storage information is displayed:
Current number of bytes being used for I/O
Current number of bytes allocated for use by I/O
Highest number of bytes allocated for use by I/O
Minimum number of bytes required for I/O to prevent deadlocks
Maximum number of bytes that can be allocated for I/O
DYNAMIC, indicating that the maximum value was dynamically calculated by TDP, or
STATIC, indicating that the value was set manually by the SET STORAGE command
Example
DISPLAY STORAGE
151

DISPLAY TDP
DISPLAY TDP
Purpose
Displays the status of TDP.
Syntax
DISPLAY
D
TDP
FZAPB024

Usage Notes
When the DISPLAY TDP command is executed, TDP displays information on the following
items:
Item
Description
RUN command
(May not always appear.)

If the RUN command has not been entered, a message stating that fact is
displayed first, preceding the other settings.
Otherwise, only the following settings are shown in the display.
TDP release
The release identifier for TDP.
COMCHAR
Current subsystem command character for TDP.

This is set using the TDP command, INITIAL COMCHAR.
TDP MAXSESS
Maximum number of sessions currently allowed for TDP.

This is determined by the TDP SET MAXSESS command.
LOGONS
Status of logons (enabled or disabled).

This is modified using the ENABLE LOGONS and DISABLE LOGONS
commands.
SERVER MAXSESS
Maximum number of sessions supported by the CPs that are currently

operational.
This value can vary during recovery from Teradata Database restarts as the
status of the SPs vary.
I/O MODE
Mode used by TDP to send I/O to the Teradata Database (EXCP, EXCPVR,
IOSDRIVR).
The I/O mode is set using the INITIAL IOMODE command.
IAC MODE
z/OS communication mode (SVC or PC).
SECURITY EXIT
State of the TDP User Security Interface (TDPUSEC), enabled or disabled.

This is modified using the ENABLE USEC and DISABLE USEC commands.
152

DISPLAY TDP
Item
Description
TEST
State of the TEST flag (enabled or disabled).

This is modified using the ENABLE TEST and DISABLE TEST commands.
MONITOR EXIT
State of the TDP User Transaction Collection Exit (TDPUTCE), enabled or

disabled.
This is modified using the ENABLE TMON and DISABLE TMON
commands.
LOGON EXIT
State of the TDP User Logon Exit interface (TDPLGUX), enabled or

disabled.
This is modified using the ENABLE LGUX and DISABLE LGUX
commands.
CHECKSUM
State of the checksum error detection setting on the Teradata Database for
CIC-type CPs, enabled or disabled.
This is modified using a DBS console command. (See the Teradata DBS
Operators Guide.)
SECLOGON
State of the Security Logon (SECLOGON) feature, and whether its

messages option is enabled or disabled.
This is modified using the MODIFY SECLOGON command.
TIME MSGS
State of the time messages, enabled or disabled.

This is modified using the ENABLE TIME and DISABLE TIME commands.
UAX
State of the TDP User Address Space Exit interface (TDPUAX), enabled or
disabled.
This is modified using the ENABLE UAX and DISABLE UAX commands.
SESSION RESERVE
State of the session reserve setting, enabled or disabled.

This is modified using the ENABLE SESSION RESERVE and DISABLE
SESSION RESERVE commands.
SESSION STATUS
State of the SESSION STATUS setting, enabled or disabled.

This is modified using the ENABLE SESSION STATUS and DISABLE
SESSION STATUS commands.
SESSION DETAIL
State of the SESSION DETAIL setting, enabled or disabled.

This is modified using the ENABLE SESSION DETAIL and DISABLE
SESSION DETAIL commands.
POOL STATUS
State of the POOL STATUS setting, enabled or disabled.

This setting is modified using the ENABLE POOL STATUS and DISABLE
POOL STATUS commands.
POOL DETAIL
State of the POOL DETAIL setting, enabled or disabled.

This setting is modified using the ENABLE POOL DETAIL and DISABLE
POOL DETAIL commands.
153

DISPLAY TDP
Item
Description
SHUTDOWN
STATUS
(May not always appear.)
TDP USERID
Userid for TDP internal sessions.
If a SHUTDOWN command has been entered and has not yet completed,
the above settings are followed by a message that an orderly, quick, or cancel
shutdown is in progress.
This setting can be modified using the SET USERID command.

USERID CHARSET
Name of the character set associated with the TDP USERID.

This setting can be modified using the SET CHARSET command.
TDP CHARSET
Name of the default TDP character set.

This setting reflects the Databases configuration of the Logical Host, and so
cannot be modified using a TDP command.
Example
D
Completion Message
TDP2010
TDP0550
TDP0551
TDP0556
TDP0552
TDP0570
TDP0572
TDP0573
TDP2012
TDP0400
TDP0392
TDP0395
154
RELEASE: TDP.06.01.00
COMCHAR: OFF, TDP MAXSESS: 1024
LOGONS: ENABLED , SERVER MAXSESS: 120
I/O MODE: EXCP, IAC MODE: IUCV
SECURITY EXIT: ENABLED, TEST: DISABLED
MONITOR EXIT: ENABLED, LOGON EXIT: ENABLED
CHECKSUM: DISABLED
TIME MSGS: ENABLED, UAX: DISABLED
SESSION STATUS: DISABLED, DETAIL: DISABLED
SESSION RESERVE: ENABLED
TDP USERID: TDPUSER, USERID CHARSET: EBCDIC
TDP CHARSET: EBCDIC

DISPLAY TDPSTATS
DISPLAY TDPSTATS
Purpose
Displays the current status (enabled or disabled) of the TDPSTATS function.
Syntax
DISPLAY
TDPSTATS
DISP
FE0CA044

Usage Notes
TDPSTATS is enabled with the ENABLE TDPSTATS command, and disabled with the
DISABLE TDPSTATS command.
Example
DISP TDPSTATS
Completion Message
TDP2031 TDPSTATS ID DISABLED
155

ENABLE IRF
ENABLE IRF
Purpose
Enables TDP internal sessions that are used for 2PC in-doubt resolution.
Syntax
ENABLE
IRF
ENA
FZAPB025
Usage Notes
This command enables the In-doubt Resolution Facility (IRF), which consists of two
TDP-internal sessions used for 2PC in-doubt resolution. The result of the ENABLE IRF
command is that the two internal sessions are logged on to the Teradata Database. If no other
sessions are logged on, the status display on the RDBMS console changes from Logon/Quiet
to Logon.
The ENABLE IRF command typically is issued after a DISABLE IRF command is completed.
For more information see DISABLE IRF earlier in this chapter.
Enabling IRF allows automatic in-doubt resolution and the execution of TDP commands for
manual in-doubt resolution (COMMIT, ROLLBACK, and DISPLAY INDOUBT).
The userid for both sessions defaults to TDPUSER, but can be changed using the SET
USERID command. By default, the userid is in EBCDIC, but a different character set can be
specified using the SET CHARSET command. The current userid and character set can be
displayed using the DISPLAY TDP command. When a specified character set is not available,
the following error message displays:
TDP0394 CHARACTER SET charactersetname IS NOT AVAILABLE.
Example
ENA IRF
Completion Message
TDP0444 type SESSION ESTABLISHED
where:
type is either:
RBM (Resolver Base Module) or
LOG
Usually, one message is displayed for the RBM session and another is displayed for the LOG
session.
If the Database rejects one of the sessions, the following message provides the specific
Database error code:
156

ENABLE IRF
TDP0427 UNEXPECTED ERROR/FAILURE PARCEL, CODE=nnnn FOR THE type SESSION
For example, if 'nnnn' is 3004, the userid was not defined to the Database.
157

ENABLE LGUX
ENABLE LGUX
Purpose
Causes TDP to begin passing logon requests to TDP User Logon Exit Interface (TDPLGUX).
Syntax
ENABLE
LGUX
ENA
FZAPB026
Usage Notes
TDPLGUX is enabled when TDP starts. If TDPLGUX is subsequently disabled using the
DISABLE LGUX command, it can be re-enabled using the ENABLE LGUX command.
When the ENABLE LGUX command is executed, TDP loads the TDPLGUX module into
main memory and begins passing logon requests to the module.
Example
ENA LGUX
Completion Message
TDP0911 TDP USER LOGON EXIT INTERFACE ENABLED
158

ENABLE LOGONS
ENABLE LOGONS
Purpose
Causes TDP to begin accepting logon requests from application programs.
Syntax
ENABLE
LOGONS
ENA
FZAPB027
Usage Notes
When TDP starts, logons are not enabled. During TDP initialization, the ENABLE LOGONS
command should be executed to allow applications to begin processing requests.
After the ENABLE LOGONS command is executed, TDP begins forwarding logon requests to
the Teradata Database for processing.
Example
ENA LOGONS
Completion Message
TDP857 LOGONS ENABLED
159

ENABLE POOL
ENABLE POOL
Purpose
Enables logons to one or more pools.
Syntax
ENABLE
POOL
ALL
ID poolid
ENA
FZAPB028
where:
Syntax Element.
Description
poolid
Unique identifier of the pool that is to be enabled.
ALL
Specifies that all pools be enabled.
Usage Notes
The ENABLE POOL command is used to enable logons for a pool that has been disabled by
the DISABLE POOL command. When a session to be used for session pool assignment is
started, a TDP0800 message is produced; when such a session ends, a TDP0801 message is
produced.
Example 1
ENA POOL ID ACTR04
Completion Message
TDP881 POOL ID: ACTR04 IS NOW ENABLED
Example 1
ENA POOL ALL
160

ENABLE POOL DETAIL
ENABLE POOL DETAIL

Purpose
Causes TDP to produce a message when a session is not satisfied from a session pool.
Syntax
ENABLE
ENA
POOL
DETAIL
DET
ID poolid
ALL
FZAJCM03
Usage Notes
If POOL DETAIL is enabled, one message of the following type is produced for each session
pool for which the session is not eligible:
TDP310n POOL name INELIGIBLE (reason): JOB name
If the session is eligible for a session pool but the pool cannot be used, a message of the
following type is produced:
TDP311n POOL name ELIGIBLE BUT reason: JOB name
If the session is not eligible for a session pool, a message of the following type is produced:
TDP312n NO POOL ELIGIBLE (reason): JOB name
Care should be exercised when enabling POOL DETAIL since many messages may result. One
message will be produced for each session for each session pool that is not eligible.
When TDP is started, POOL DETAIL is disabled. To subsequently enable POOL DETAIL, use
the ENABLE POOL DETAIL command. The current setting can be displayed using the
DISPLAY TDP command. POOL DETAIL can be disabled using the DISABLE POOL DETAIL
command.
Example
ENABLE POOL DETAIL
Completion Message
TDP0401 POOL DETAIL HAS BEEN ENABLED
161

ENABLE POOL STATUS
ENABLE POOL STATUS

Purpose
Causes TDP to produce a message when a session satisfied from a session pool ends.
Syntax
ENABLE
ENA
POOL
STATUS
STA
ID poolid
ALL
FZAJCM02
Usage Notes
When TDP is started, POOL STATUS is disabled. To subsequently enable POOL STATUS, use
the ENABLE POOL STATUS command. The current setting can be displayed using the
DISPLAY TDP command. POOL STATUS can be disabled using the DISABLE POOL STATUS
command.
If POOL STATUS is enabled, the following type of message is produced when a new session is
satisfied from a session pool:
TDP0802 POOL name, nn AVAILABLE: SESSION nn, JOB name STARTED
and the following type of message is produced when a session using a session pool ends:
TDP0803 POOL name, nn AVAILABLE: SESSION nn, JOB name STARTED
162

ENABLE SECLOGON
ENABLE SECLOGON
Purpose
Enables the security logon function that provides an interface to the System Authorization
Facility (SAF) on z/OS client systems.
Note: You must enable the security logon function manually either from the system console
or via the TDPPARM command list. It does not automatically enable at TDP initialization like
TDPLGUX, TDPUSEC, or TDPUTCE.
Syntax
ENABLE
ENA
SECLOGON
NOMSGS
MSGS
CLASS xxxxxxxx
FZAPB094
where:
Syntax Element
Specification that
NOMSGS
the messages option that suppresses messages to the system console in

response to logon validation failure or denied access.
MSGS
the messages option that enables messages to the system console in response
to logon validation failure or denied access.
xxxxxxxx
an class for SAF processing. The default class is FACILITY.
Usage Notes
TDP responds to the ENABLE SECLOGON command with a TDP2108 message indicating
SECLOGON will only work under z/OS, and only when IACMODE XMS has been selected at
TDP initialization.
To use SECLOGON in a Multi-User Address Space (MUSAS) environment like CICS or IMS,
obtain the security userid from the external security manager via TDPUAX, and pass that
information to TDPLGUX. Once this is done TDPLGUX can direct SECLOGON to use the
TDPUAX-supplied security userid for validation purposes. For more details, consult your
external security managers documentation or contact the vendors technical support.
Example
ENABLE SECLOGON
Completion Message
TDP2108 SECLOGON: ENABLED, DIAGNOSTIC MSGS: DISABLED
CLASS: FACILITY
163


Purpose
Causes TDP to produce a message when a session ends that indicates the elapsed time that the
session spent within the application and within the Teradata Database.
Syntax
ENABLE
ENA
SESSION
DETAIL
DET
FZAPA099
Usage Notes
When TDP starts, Session Detail is disabled. The current setting can be displayed using the
When Session Detail is enabled and a session ends, the following type of message is produced
to indicate the total elapsed time that the session spent within the application and within the
Teradata Database:
TDP0846 SESSION nnnn, JOB jobname: SERVER(time), APPL(time)
Example
Completion Message
TDP0401 SESSION DETAIL HAS BEEN ENABLED
164


Purpose
Causes TDP to reserve session capacity for use in the event of a failure of a session processor
(SP). This reserve reduces the maximum number of sessions TDP can control during its
current run.
Syntax
ENABLE
SESSION
ENA
RESERVE
RES
FZAPB029
Usage Notes
When TDP starts, the Session Reserve is enabled. If the Session Reserve has been subsequently
disabled with the DISABLE SESSION RESERVE command, you can use the ENABLE
SESSION RESERVE command to enable the Session Reserve again.
When Session Reserve is enabled and more than one SP is operational, TDP reserves a number
of sessions equal to the capacity of one SP. This is to ensure that if a single SP fails, its sessions
can be switched to other SPs that were started by this TDP.
This command affects the value of SEVER MAXSESS, as displayed in the output from the
DISPLAY TDP command. This is a separate limit from the value of TDP MAXSESS, which is
controlled by the SET MAXSESS command. The maximum number of sessions that can be
logged on through this TDP is the lower of these two values.
from an application is refused with an error code of CLI0513.
Example
ENA SESSION RES
Completion Message
TDP400 SESSION RESERVE: ENABLED
165


Purpose
Causes TDP to produce a message when a session starts or ends.
Syntax
ENABLE
ENA
SESSION
STATUS
STA
FZAPA098
Usage Notes
When TDP starts, Session Status is disabled.
The current setting can be displayed using the DISPLAY TDP command.
If Session Status is enabled, the following type of message is produced when a session starts:
TDP0899 SESSION nnnn STARTED, JOB jobname
and the following type of message is produced when a session ends:

TDP0898 SESSION nnnn ENDED, JOB jobname
These messages had previously been controlled by the ENABLE TEST command. For
compatibility, they continue under TEST control until an ENABLE SESSION STATUS or
DISABLE SESSION STATUS is issued, after which TEST has no effect on these messages.
Example
Completion Message
TDP0401 SESSION STATUS HAS BEEN ENABLED
166

ENABLE SMF
ENABLE SMF
Purpose
Enables the recording of all System Management Facility (SMF) records. You can also limit the
recording to specific record subtypes.
In VOS3, this applies to SMS records.
Syntax
ENABLE
SMF
ALL
ENA
SUB n
FZAPB030
where:
Syntax Element
Is the specification that recording for . . .
ALL
all SMF record types is to be enabled.
SUBn
certain SMF types is to be enabled.

There are four subtypes:
1: Session Termination
2: Security Violation
3: CPActivity
4: TDP Shutdown
5: Structure-protocol Termination
Usage Notes
When TDP starts, SMF recording is enabled for subtypes 1 through 4. To disable SMF
recording, use the DISABLE SMF operator command.
The ALL argument is the default for this command. If you enter just the ENABLE SMF
command with no arguments, recording is enabled for all SMF record subtypes.
To enable the recording of a specific SMF record subtype, use the SUBn argument, where n is
the number of the SMF record subtype to be recorded.
Example
ENA SMF
ENA SMF SUB1
Completion Message
TDP0594 SMF RECORDING ENABLED
167

ENABLE TDPSTATS
ENABLE TDPSTATS
Purpose
TDPSTATS measures the performance and assesses the efficiency of data movement between
TDP and the Teradata Database. TDPSTATS collects the following information over the
course of one-minute intervals, then displays it on a normalized per second basis:
EXCPS input execute channel program (data blocks)
Messages received
Input retries
Kbytes received
EXCPs output
Messages sent
Transmission retries
Kbytes sent
This data is useful for application tuning as well as performance benchmarking. The Kbytes in
and Kbytes out values provide an overall measure of throughput efficiency.
Syntax
ENABLE
TDPSTATS
ENA
FE0CA042
Usage Notes
TDPSTATS is stopped by the DISA TDPSTATS command. Use the DISPLAY TDPSTATS
command to determine the status of TDPSTATS.
You can configure TDPSTATS to route output to the system console, or to a data set. The
advantage of routing to the console is that you can view the data in real time, make
adjustments to various tuning parameters, and observe the results immediately. The
disadvantage is that the console can become cluttered with messages from TDPSTATS. The
advantage of routing to a data set is that the data can be collected automatically and postprocessed using a product such as Microsoft Excel to produce historical graphs or charts that
can depict performance trends over longer periods of time. The disadvantage is the
concomitant loss of immediacy.
To route data to the console, enter ENA TDPSTATS. At one-minute intervals, TDSPTATS
writes two messages to the console (one for input statistics and the other for output statistics).
This continues until TDPSTATS is terminated by entering DISA TDPSTATS, or until a TDP
shutdown occurs.
To route data to a data set, include a DD statement to identify a sequential data set in the JCL
for the TDP started task. The DDNAME of this file must be TDPSTATS. Generation data
groups (GDGs) are acceptable, as is SYSOUT.
168

ENABLE TDPSTATS
At one-minute intervals, TDPSTATS writes one record to this file using QSAM. Following are
typical entries:
TDPSTATS FOR TDPC (VALUES ARE PER SECOND SAMPLED AT ONE-MINUTE INTERVALS
YYYY.DDD,HH:MM,EXCPIN,MSGSIN,RTRYIN,KBYTIN,EXCPOU,MSGSOU,RTRYOU,KBYTOU
1999.215,09:51,000008,000064,000000,001455,000007,000063,000000,001593
1999.215,09:52,000000,000000,000000,000000,000000,000000,000000,000000
1999.215,09:53,000000,000000,000000,000000,000000,000000,000000,000000
The first record identifies the output as being generated by TDPSTATS for a specific TDP (in
this case, TDPC).
The second record provides a legend for easier readability. Note that the actual data values are
comma-separated; this facilitates their input into a spreadsheet program like Excel.
In both console and data set modes, if the device configuration is changed (for example,
starting and or stopping one or more CPs) while TDPSTATS is active, data associated with the
current interval is discarded and TDPSTATS will be re-initialized. This results in the loss of
data from one one-minute interval.
In data set mode, if an OPEN/CLOSE/EOV failure or I/O error associated with the TDPSTATS
file occurs, TDPSTATS is permanently disabled for the life of the TDP address space, and
restarting TDPSTATS will require restarting TDP.
Example
ENABLE TDPSTATS
Completion Message
TDP2500 TDP THROUGHPUT STATISTICS REPORTER ENABLED
169

ENABLE TEST
ENABLE TEST
Purpose
Causes TDP to start writing informational or diagnostic messages to the system console.
Syntax
ENABLE
TEST
ENA
FZAPB031
Usage Notes
When TDP starts, TEST mode is not enabled. TEST can be enabled by executing the ENABLE
TEST operator command.
After ENABLE TEST is issued, informational messages produced by TEST mode are written to
the system console to indicate the starting and ending of sessions. This use is deprecated,
replaced by use of ENABLE and DISABLE SESSION STATUS.
After ENABLE TEST is issued, more comprehensive information is provided for the DISPLAY
SESSIONS command. This use is deprecated, replaced by the DETAIL operand on the
DISPLAY SESSIONS command.
Example
ENA TEST
Completion Message
TDP0541 TEST MODE ENABLED
170

ENABLE TIME
ENABLE TIME
Purpose
Causes TDP to send the time from the client to the Teradata Database.
Syntax
ENABLE
ENA
TIME
TIM
FZAPB032
Usage Notes
If neither an ENABLE TIME nor a DISABLE TIME command is issued, the default action is
specified in HSISPB. While HSISPB can be customized as necessary, as distributed, DISABLE
TIME is the default.
If you are using a Teradata Database release between V1R4.1 and V1R5.1, inclusive, the
ENABLE TIME feature is supported only for DBC/1012 configurations controlled by a Model
2 Access Module Processor (AMP) or below. If the configuration at your site does not include
a Model 2 AMP, you may want to include the DISABLE TIME command in the TDPPARM
data set to reduce meaningless channel traffic.
For releases prior to V1R4.1 or V1R5.2 and above, ENABLE or DISABLE TIME function as
expected.
To set the time, use the RDBMS console command, SET TIME.
Example
ENA TIM
Completion Message
TDP0596 HOST TO SERVER TIME MESSAGES: ENABLED
171

ENABLE TMON
ENABLE TMON
Purpose
Enables TDP calls to the User Transaction Collection Exit (TDPUTCE) routine, which is used
to collect statistics about requests and responses that traverse TDP.
Syntax
ENABLE
TMON
ENA
FZAPB033
Usage Notes
When TDP starts, TDPUTCE is enabled. If TDPUTCE is subsequently disabled using the
DISABLE TMON operator command, the routine can be re-enabled using the ENABLE
TMON command.
When the ENABLE TMON command is executed, TDP loads the TDPUTCE module into
main memory and begins passing all requests and responses to the module.
Example
ENA TMON
Completion Message
TDP0921 TDP USER MONITOR EXIT INTERFACE ENABLED
172

ENABLE TRAP
ENABLE TRAP
Purpose
Enables a TDP internal diagnostic trap. The trap causes the TDP to perform a specified action
if the trap conditions occur.
Syntax
ENABLE TRAP
PERMIO
CHECKSUM
NAME name
CHE
BADCP
SERVERPV
CLIENTPV
NOREAD
NOR
FAULTRSP
ACTION
ABEND
SNAP
IMPRSTRT
IMP
ACTION
ABEND
SNAP
UNSOLRSP
UNS
ACTION
ABEND
SNAP
2416A006
where:
Syntax Element
Indicates
PERMIO
Trap a CP permanent I/O error.
BADCP
Trap an invalid CP device.
SERVERPV
Trap a Teradata Database protocol violation.
CLIENTPV
Trap a client protocol violation.
NORead
Trap detection of the unexpected lack of a read when CP is recovering from a

loss of communication with the Database.
Note: Lower case letters represent optional characters.
173

ENABLE TRAP
Syntax Element
Indicates
FAULTRSP
Trap a faulty response. A faulty response is one whose parcels do not exactly
fill the response.
IMPrstrt
Trap detection of an implicit CP restart. An implicit CP restart occurs when

TDP was not informed of the restart of a CP directly by the CP, but rather
detects the restart by subsequent errors returned by the Teradata Database.
UNSolrsp
Trap detection of an unsolicited response. An unsolicited response occurs

when TDP receives a response from the Teradata Database that is not
associated with a request that had been sent by TDP.
ABEND
Terminate TDP if the trap condition occurs. This is the default.
SNAP
Record the event to TDPSNAP if the trap condition occurs.
CHECKSUM
Indication that a checksum validation failure for a CCU-type CP is to be

trapped.
name
Trap name; length is 1 to 8 characters. If omitted, TDP supplies a name.
Usage Notes
The trap can be removed by using the DISABLE TRAP command.
For event types that do not support the ACTION operand, or when the ACTION operand is
not specified, ABEND is the implied action.
This command is intended for use in consultation with Teradata Customer Support
personnel.
Example
ENABLE TRAP PERMIO
Completion Message
TDP0401 TRAP TRAP0001 HAS BEEN ENABLED
174

ENABLE UAX
ENABLE UAX
Purpose
Causes TDP to pass requests to the User Address Space Exit Interface (TDPUAX).
Syntax
ENABLE
UAX
ENA
FZAPB034
Usage Notes
TDPUAX is available only in the z/OS or VOS3 environment.
To disable TDPUAX, use the DISABLE UAX command.
Example
ENA UAX
Completion Message
TDP0597 TDP USER ADDRESS SPACE EXIT INTERFACE ENABLED
175

ENABLE USEC
ENABLE USEC
Purpose
Causes TDP to begin passing security and logon violations information detected by the
Teradata Database and by the User Logon Exit Interface (TDPLGUX) to the TDP User
Security Interface (TDPUSEC).
Syntax
ENABLE
USEC
ENA
FZAPB035
Usage Notes
When TDP starts, TDPUSEC is enabled. If TDPUSEC is subsequently disabled using the
DISABLE USEC operator command, the interface can be re-enabled using the ENABLE USEC
command.
When the ENABLE USEC command is executed, TDP loads the TDPUSEC module into main
memory and begins passing security violations to the module.
Example
ENA USEC
Completion Message
TDP0901 TDP USER SECURITY EXIT INTERFACE ENABLED
176

INITIAL CCU
INITIAL CCU
Purpose
Changes limits used during operation of CCU-type CPs.
Syntax
INITIAL
INI
CCU
MAXBLKNM n
MAXBLKSZ n
MAXCKSUM n
FE0CQ049
where:
Syntax Element
Description
MAXBLKNM
Maximum number of channel blocks for any I/O.

The value can be 1 through 255; the default is 4.
MAXBLKSZ
Maximum size of a channel block used for I/O.

The value can be 320 through 65535; the default is 65535.
MAXCKSUM
Number of checksum rejections at which the CP will become unusable. A value

of zero, the default, indicates that the CP will never be considered unusable due
to checksum rejections.
Usage Notes
You can display CCU limits with the DISPLAY CCU command.
INITIAL CCU is intended for use in consultation with Teradata Customer Service personnel.
These values are not necessarily the values that will be used by the CP. Rather, they are TDP's
preferences but can be negotiated to other values by the Teradata Database when
communication for each CP is established. While the Teradata Database can not increase a
value, it can decrease it. For MAXCKSUM, the value could be forced to zero, thereby allowing
any number of checksum rejections.
Example
INITIAL CCU MAXBLKNM 4
INITIAL CCU MAXBLKSZ 32767
INITIAL CCU MAXCKSUM 13
177

INITIAL DLYTIME
INITIAL DLYTIME
Purpose
Sets the time interval for issuing reminders that all communication with the Teradata
Database has been lost.
Syntax
INITIAL
INI
DLYTIME ssss
FZAPB050
where:
Syntax Element.
Description
ssss
Time interval in seconds.

This interval can not be less than 60 seconds.
Usage Notes
If an interval of less than 60 seconds is specified, 60 seconds is used.
Example
INIT DLYTIME 90
178

INITIAL IACMODE
INITIAL IACMODE
Purpose
Changes the mode of communication between TDP and an application program.
Syntax
where:
Syntax Element
Description
SVC
Specification that the communication mode be a supervisor call (SVC).

This option is valid only in the z/OS environment, and is equivalent to the old
option, CSA.
nnn
Number of the SVC to be used.

Legal values range from 200 through 255. The value selected must not be
currently defined to the rating system. If a value is not specified, 245 is used
DYNAMIC
Indication that the SVC is to be installed into z/OS by TDP when started, and
removed by TDP upon stopping.
If DYNAMIC is not specified, the SVC must be installed before starting TDP.
(See theTeradata Tools and Utilities Installation Guide for IBM z/OS)
PC
Specification that the communication mode be a program call (PC).

This option is only valid in the z/OS environment, where it is the default. It is
equivalent to the old option, XMS.
Usage Notes
The DYNAMIC option must not be specified if multiple TDPs are to use the same SVC
number. If DYNAMIC is specified, the first TDP to be stopped removes the SVC from the
system, making it unavailable for the other TDPs.
When the Teradata Database uses more than one version of the TRDTMAS (z/OS) or
TRDTHAS (VOS3), each version is identified by a unique SVC number, nnn.
The version of the SVC used by an application that uses Call-Level Interface (CLI) routines is
controlled by the HSISPB module.
Example 1
INIT IACMODE SVC
179

INITIAL IACMODE
Example 2
INITIAL IACMODE PC
180

INITIAL IOBUFS
INITIAL IOBUFS
Purpose
Increase the number of I/O buffers for CPs not requiring the CCU operand on the START
command. The command overrides the system defaults.
Syntax
INITIAL
INI
IOBUFS number
FZAPB052
where:
Syntax Element
Description
number
Number of I/O buffers.
Usage Notes
The buffers requested by this command are not used for CPs that require the CCU operand on
the START command. If all CPs are of this type, then any use of INITIAL IOBUFS wastes
storage.
The INITIAL IOBUFS command overrides the system default and is the only way to increase
the numbers of I/O buffers before TDP initialization. The system default is a function of the
number of CPs and the workload. This default is appropriate for most situations.
The INITIAL IOBUFS command should be used if the D CELLS command shows an excessive
number of GETMAINS and/or WAIT COUNTS on the I/O buffers. If this occurs, consult with
Teradata customer support personnel to determine the optimum number of I/O buffers.
Example
INIT IOBUFS 32
181

INITIAL IOMODE
INITIAL IOMODE
Purpose
Chooses the mode used by TDP to send I/O to the Teradata Database.
Syntax
where:
Syntax Element
Is the specification that . . .
EXCP
I/O be performed using EXCP
EXCPVR
I/O be performed using EXCPVR.

This is the default in the z/OS environment.
IOSDRIVR
I/O be performed using a TDP IOS Driver.

This option is only valid in the z/OS environment.
Usage Notes
Use of IOSDRIVR reduces the I/O path length between TDP I/O tasks and the system I/O
supervisor. Use of the option also avoids Supervisor Call (SVC) interrupts by enabling TDP to
pass any new I/O request directly to the IOS.
For z/OS, use of EXCPVR or IOSDRIVR, allows 31bit virtual storage for I/O buffers.
For z/OS, use of EXCPVR or IOSDRIVR results in virtual storage for I/O being fixed in real
storage while it is allocated, so real storage utilization can be increased. For CCU-type CPs,
such storage is dynamically obtained, freed, or cached as needed; for CIC-type CPs, the
storage comprises TDP I/O cells.
182

INITIAL IOMODE
Example 1
INIT IOMODE EXCP
Example 2
INITIAL IOMODE EXCPVR
Example 3
INIT IOMODE IOSDRIVR
183

INITIAL JOBWAIT
INITIAL JOBWAIT
Purpose
Chooses the amount of time that an application can be in a wait state before TDP initiates an
activity to prevent the application from being timed out by the operating system.
Syntax
INITIAL
INI
JOBWAIT mmmm
FZAPB054
where:
Syntax Element
Description
mmmm
Time, in minutes.
A value of zero indicates that TDP does not attempt to prevent timeouts. This
value must be less than 1440 (number of minutes in a day).
Usage Notes
See Preventing Application Time-out on page 35 in for more information.
Example
INIT JOBWAIT 2
184

INITIAL LSQA
INITIAL LSQA
Purpose
Controls the use of LSQA in address spaces communicating with the RDBMS.
Syntax
INITIAL
INI
LSQA
24BIT
31BIT
FZAPB055
where:
Syntax Element.
Description
24BIT
24-bit storage is to be used for LSQA working storage.

This is the default configuration if you do not use the INITIAL LSQA
command.
31BIT
31-bit storage is to be used for LSQA working storage.
Usage Notes
31BIT can only be specified if all TDPs on the system are running at the current level and
specify the 31-bit value.
Example
INIT LSQA 31BIT
185

INITIAL MSGPREF
INITIAL MSGPREF
Purpose
Controls the TDP identifier that normally appears before the message prefix. The initial
setting is ON, which causes all messages to be preceded by the last character of the TDP
identifier, a colon and a blank. OFF suppresses this TDP identifier prefix.
Syntax
INITIAL
INI
MSGPREF
ON
OFF
COM
NOCOM
FZAPB056
where:
Syntax Element
Description
ON
Displays the TDP identifier prefix for all messages.
OFF
Suppresses display of the TDP identifier prefix for all messages.
COM
Displays the COMCHAR preceding the TDP identifier.
NOCOM
Suppresses the COMCHAR for all messages.
Usage Notes
Specifying MSGPREF OFF only does not suppress the COMCHAR, which precedes all TDP
messages. To suppress the COMCHAR, specify NOCOM, which is optional. If NOCOM is
specified, the communication character appears as a blank. When specifying these operands,
ON or OFF must precede COM or NOCOM.
The default condition is ON and COM for all TDP messages.
Example
INIT MSGPREF OFF NOCOM
186

INITIAL OSSISUFX
INITIAL OSSISUFX
Purpose
Associates a TDP with the HSI Operating System Subsystem Interface.
If the subsystem uses SVC mode, TDP is associated with a version of HSIOSSI. If the
subsystem uses PC mode, TDP should be associated with a version of HSI Program Call
Services (HSISXMS).
Syntax
INITIAL
INI
OSSISUFX
OSSI
suffix_character
FZAPB057
where:
Syntax Element
Description
suffix_character
Suffix character of the HSIOSSI or HSISXMS module to be used.

The character can be alphabetic, numeric, or $, #, or @.
Usage Notes
When a Teradata Database uses more than one TDP subsystem (for example, a test TDP
subsystem and a production TDP subsystem), each subsystem can use a different version of
the HSIOSSI (SVC mode) or HSISXMS (PC mode) module to communicate with an
application address space. To enable a TDP to distinguish between HSIOSSI or HSISXMS
modules, a suffix is appended to the name of each module during the installation of Teradata
Database software on the z/OS client.
When TDP starts, the OSSISUFX is not set. When the INITIAL IOMODE command is
executed, the version of HSIOSSI or HSISXMS identified by the suffix character must be
compatible with the version of the TDP to be used.
Example
INIT OSSI #
187

INITIAL PCSUFX
INITIAL PCSUFX
Purpose
Associates a TDP with the version of the TDPNSPCI module that is used by the subsystem in
which TDP is running. (z/OS only)
Syntax
INITIAL
INI
PCSUFX suffix_character
FZAPB058
where:
Syntax Element
Description
suffix_character
Suffix character of the TDPNSPCI module to be used. The character can be

alphabetic, numeric, or $, #, or @.
If not specified, the default is I.
Usage Notes
When a Teradata Database uses more than one TDP subsystem (for example, a testing TDP
subsystem and a production TDP subsystem), each subsystem can use a different copy of the
non-space-switched PC program (TDPNSPCI) module to communicate with an application
address space. To enable a TDP to distinguish between TDPNSPCI modules, a suffix is
appended to the name of each module during the installation of Teradata Database software
on the client.
The TDPNSPCI module is used only if TDP runs in communication mode PC (Program
Call).
Example
INIT PCSUFX $
188

INITIAL TRUNCRSP
INITIAL TRUNCRSP
Purpose
Specifies if response truncation is to be indicated by a return code.
Syntax
INITIAL
INI
TRUNCRSP
RC
NORC
FE0CB051
where:
Syntax Element
Description
RC
Indicate truncation in return code

If not specified, the default is RC.
NORC
Suppress any indication that the response has been truncated
Usage Notes
There is no command to display the current setting.
This command is intended for use in consultation with Teradata Customer Support
personnel.
Example
INIT TRUNCRSP NORC
189

LOGOFF
LOGOFF
Purpose
Forces one or more sessions to be logged off the Teradata Database.
Syntax
LOGOFF
LOG
SESSIONS
SES
sessnumber
ALL
JOB jobname
TASK taskid
SUPPRESS
SUCCESS
WARNING
ALL
FZAPC036
where:
Syntax Element
Description
sessnumber
Session number, in decimal, of the session to be logged off. Leading zeros

need not be specified.
ALL
Specification that all sessions are to be logged off.
jobname
Job name (in all environments), or

TSO user identification (in z/OS only) whose sessions are to be logged off.
TSS user identification (in VOS3 only) whose sessions are to be logged off.
taskid
z/OS or VOS3 TCB address that established the sessions to be logged off.
SUCCESS
Specification that messages indicating success of the command will be

suppressed.
WARNING
Specification that messages indicating warnings that no sessions were affected

will be suppressed.
ALL
Specification that both success and warning messages will be suppressed.
Usage Notes
When the LOGOFF command is executed, a logoff request is sent to the Teradata Database for
each session to be logged off. When the SES ALL operand is used, Teradata Database logons
are disabled when all sessions have been logged off.
Outstanding requests for sessions to be logged off are aborted, and any results are returned to
the requesting application. Subsequent requests for a logged-off session are returned to an
application with an error message.
To log off a session, issue the LOGOFF command from the TDP that the session is running on.
190

LOGOFF
Performance Monitor ABORT SESSION Command

There is a separate performance monitor command, ABORT SESSION, that is executed from
the RDBMS console. The ABORT SESSION command can log off any Teradata Database
session on any mainframe or LAN client. It can also log off sessions based on username only
(the host id and session number are not required).
Example 1
LOGOFF SES 1259
Completion Message
TDP0864 LOGOFF COMMAND ACCEPTED FOR SESSION 1259
Example 1
LOGOFF SES ALL
Completion Message
TDP0860 LOGOFF INITIATED FOR number_of_sessions SESSIONS
Example 1
LOGOFF JOB AWVRET
Completion Message
TDP0850 JOB AWVRET number_of_sessions LOGOFFS INITIATED
191

LOGOFF POOL
LOGOFF POOL
Purpose
Ends a pool immediately by forcing the logoff of pool sessions that are in use by application
programs.
Syntax
LOGOFF
LOG
POOL
ID poolid
ALL
FZAPA037
where:
Syntax Element
Description
poolid
Unique identifier of the pool that is to be logged off.
ALL
Requests that all pools be logged off.
Usage Notes
The LOGOFF POOL command affects only pool sessions that are being used by applications.
The LOGOFF POOL command terminates any pool sessions that are in use and disables their
associated pools. The pools still exist, but they are disabled.
To use the pools again, use the ENABLE POOL command.
To completely eliminate existing pools in an orderly manner, use the STOP POOL command.
Example 1
LOGOFF POOL ID ACTR04
Example 2
LOGOFF POOL ALL
Completion Messages
192
When LOGOFF
POOL . . .
This message is displayed . . .
begins processing
TDP0877 LOGOFF POOL INITIATED FOR POOL ID: poolid
finishes processing
TDP0878 POOL ID: poolid STOPPING

MODIFY POOL
MODIFY POOL
Purpose
Increases or decreases the number of sessions in a pool.
Syntax
MODIFY
MOD
POOL ID
poolid NUM number

FZAPB038
where:
Syntax Element
Description
poolid
Unique identifier of the pool that is to be modified.
number
Modified number of sessions desired for the pool.
Usage Notes
The MODIFY POOL command can be used to supplement the number of sessions in a pool
that was originally unable to acquire the desired number of sessions because there was
insufficient session capacity.
When supplementing the number of pool sessions, the MODIFY POOL command is entered
after system session load has been reduced.
If the modified number of sessions is equal to the current number of sessions in the pool, then
the command is rejected with an error message.
Example
MODIFY POOL ID ACTR04 NUM 30
Completion Messages
When MODIFY POOL
is executed to . . .
The resulting message is . . .
increase the number

of sessions in a pool
TDP0866 ADDING number SESSIONS TO POOL ID: poolid
decrease the number

of sessions in a pool
TDP0879 REMOVING number SESSIONS FROM POOL ID:

poolid
193

MODIFY SECLOGON
MODIFY SECLOGON
Purpose
Changes the configuration of the messages option of the security logon function that provides
an interface to the System Authorization Facility (SAF) on z/OS client systems.
Syntax
MODIFY
MOD
SECLOGON
MSGS
NOMSGS
FZAPA092
where:
Syntax Element
Is the specification of the messages option that . . .
NOMSGS
suppresses messages to the system console in response to logon validation

failure or denied access.
MSGS
enables messages to the system console in response to logon validation failure

or denied access.
Usage Notes
TDP responds to the MODIFY SECLOGON command with a TDP2108 message indicating
Example
MODIFY SECLOGON MSGS
Completion Message
TDP2108 SECLOGON: ENABLED, DIAGNOSTIC MSGS: ENABLED
194

RESOLVE
RESOLVE
Purpose
For in-doubt two-phase commit sessions, manually resolve the in-doubt status. This
command is intended for use by programmatic two-phase commit co-ordinators and cannot
be issued from any console. It is described here only for completeness.
Syntax
RESOLVE
SESSION number
COMMIT
COORD name
ROLLBACK
FORGET
JCM_D007
where:
Syntax Element
Description.
number
Number of the in-doubt session
name

The IMS system id.
Usage Notes
Used by a two-phase commit programmatic co-ordinator.
Example
RESOLVE SESSION 3253 ROLLBACK COORD IMS
Completion Message
TDP0417 SESSION 3253 HAS BEEN MANUALLY ROLLED BACK
195

ROLLBACK
ROLLBACK
Purpose
Rolls back a single 2PC in-doubt session or all 2PC in-doubt sessions for a specified
coordinator.
Syntax
ROLLBACK
ROL
ALL
COORD name
SESSION number
HOST id
FZAPB039
where:
Syntax Element
Description
ALL
Specification that all in-doubt sessions for the coordinator are to be rolled
back.
SESSION
Specification that only one session is to be rolled back.
number
Number of the in-doubt session to be rolled back.
name

The IMS system id.
id
(Optional) logical host ID, a decimal number.

The default is the host ID of the current TDP.
Usage Notes
The ROLLBACK command includes a LOGOFF action by default. The result of this command
is recorded in the InDoubtResLog on the Teradata Database.
Example 1
ROLLBACK ALL COORD TERCICS
Completion Message
TDP0420 ALL IN-DOUBT SESSIONS FOR COORDINATOR TERCICS ROLLED BACK
Example 1
ROLLBACK SESSION 3253 COORD IMS
Completion Message
TDP0403 SESSION 3253 ROLLED BACK
196

RUN
RUN
Purpose
Enables communication with the Teradata Database by allowing CPs to be started.
Syntax
RUN
RU
FZAPA040
Usage Notes
Sessions cannot be established until the RUN command is executed.
Any TDP command can be issued before the RUN command. Those commands that require
communication with the Teradata Database (for example,CP-related commands) are accepted
but do not complete. Once the RUN command is executed, any pendingCP-related commands
will complete and sessions can then be established. This gives an operator the opportunity to
enter commands that are not included in the TDPPARM data set before TDP begins
execution.
If the command used to start TDP is executed from the system console, each command in
TDPPARM is displayed at the console as it is executed, followed by a processing response. If
the RUN command is entered as part of a batch job, messages are routed to the master console
route code.
Example
RUN
197

SET CHARSET
SET CHARSET
Purpose
Establishes the character set with which userids (SET USERID) and logon strings (START
POOL) are specified in TDP commands.
Syntax
SET CHARSET character_set_name
FZAPB041
Note: The SE abbreviation is deprecated.

where:
Syntax Element
Description
character_set_name
Name of a character set known to

TDP, chosen as one of the following,
having EBCDIC characteristics:
198
EBCDIC
EBCDIC037_0E
EBCDIC273_0E
EBCDIC277_0E
HANGULEBCDIC933_1II
KANJIEBCDIC5026_0I
KANJIEBCDIC5035_0I
KATAKANAEBCDIC
SCHEBCDIC935_2IJ
TCHEBCDIC937_3IB
Or one of the following, having

ASCII characteristics:
ARABIC1256_6A0
ASCII
CYRILLIC1251_2A0
HANGUL949_7R0
HANGULKSC5601_2R4
HEBREW1255_5A0
KANJIEUC_0U
KANJISJIS_0S
LATIN1_0A
LATIN1250_1A0
LATIN1252_0A
LATIN1252_3A0
LATIN1254_7A0
LATIN1258_8A0
LATIN9_0A
SCHGB2312_1T0
SCHINESE936_6R0
TCHBIG5_1R0
TCHINESE950_8R0
THAI874_4A0
UTF8
Or UTF16 or any user-defined
character set established using the
TDP SET USERCS command.

SET CHARSET
While other names can be specified, their characteristics (codepoint for the space, comma,
apostrophe, and quotation symbols; the codepoints for control characters; the encoding
scheme, and the rules for monocasing) are assumed to be the same as the characteristics for
EBCDIC.
Usage Notes
Unless this command is specified, EBCDIC is assumed. Neither the ability of the database to
support character sets nor the existence of the specified character set is validated during the
execution of this command. Subsequent attempts to specify a database object in a TDP
command can result in errors.
The current character set can be displayed using the DISPLAY TDP command.
Example 1
SET CHARSET KANJIEBCDIC5026_0I
Example 2
SET CHARSET EBCDIC
Completion Message
TDP0396 TDP CHARSET IS NOW character_set_name
Error Messages
Possible error messages are:
TDP0504
TDP0506
TDP0535
TDP0536
TDP0502
UNKNOWN TDP COMMAND NAME: text

UNKNOWN OPERAND TO THE SET COMMAND: text
TOO FEW OPERANDS FOR THE SET CHARSET COMMAND
TOO MANY OPERANDS FOR THE SET CHARSET COMMAND
LENGTH INCORRECT FOR SET CHARSET VALUE
199

SET CHECKSUM
SET CHECKSUM
Purpose
Changes the use of checksum validation for data transfer to and from the Teradata Database
through CCU-type CPs.
Syntax
SET
CHECKSUM
ON
CHE
OFF
AUTO
AUT
EF03A073

where:
Syntax Element
Description
ON
Checksums from the Teradata Database are honored, and checksums are
always sent to the Teradata Database.
OFF
Checksums from the Teradata Database are ignored, and no checksums are
sent to the Teradata Database.
AUTO
When a checksum is received from the Teradata Database, checksums are sent
to the Teradata Database.
Usage Notes
Use the DISPLAY CHECKSUM command to display the current checksum setting.
Message
TDP2033 CHECKSUM IS NOW 'ON' (WAS 'OFF')
200

SET COMCHAR
SET COMCHAR
Purpose
Establishes or changes the communication character (comchar) that is used to link the entry
of TDP operator commands with a TDP that is to be initialized.
Syntax
SET
COMCHAR
COM
comchar
OFF
FZAPB043

where:
Syntax Element
Description
comchar
Communication character as one of the following special characters:

[.<(+|&!$*);-/,%_>?:#@=
OFF
Specification that no communication character be used to identify commands.
Usage Notes
When a TDP starts, no comchar is defined. After the SET COMCHAR command is executed
to specify a communication character for a TDP, all TDP commands subsequently entered
that are preceded by the character are interpreted as commands for that TDP.
It is not recommended that the same communication character be defined for more than one
TDP subsystem. If this is done, commands prefixed by the character are processed by all
subsystems that are assigned that communication character.
Example 1
SET COM +
Completion Message
TDP0543 COMMUNICATION CHARACTER IS NOW SET: +
Example 1
SET COMCHAR OFF
201

SET LIMIT
SET LIMIT
Purpose
Changes limits used by TDP.
Syntax
SET
LIMIT
LIM
NORESP nnnn
JCM03230600
NOR nnnn
where:
Syntax element
Description
nnnn
The number of consecutive requests that have been sent to the Database on a
CP without receiving any responses that TDP will consider excessive. At this
limit TDP will consider the CP as unresponsive and use other CPs to send
subsequent requests. If no other functional CPs exist, requests will continued
to be queued for this one. A value of zero indicates that TDP will never
consider a CP unresponsive.
Usage Notes
If this command is not used, a value of 75 is assumed.
The current value can be displayed using the DISPLAY LIMIT command.
Because SQL requests can run for unbounded time so there is no certain way to know when a
response is not forthcoming, this command is intended for use in consultation with Teradata
customer support personnel.
Example
SET LIMIT NORESP 100
202

SET MAXSESS
SET MAXSESS
Purpose
Establishes the maximum number of concurrent sessions that TDP will allow.
Syntax
SET
MAXSESS
MAXS
number_of_sessions
FZAPB044

where:
Syntax Element
Description
number_of_sessions
Maximum number of sessions, in decimal, that can be concurrently

logged on to TDP.
This operand can be set to any value between 0 and 4,294,967,295.
Usage Notes
The SET MAXSESS command limits TDP usage of Teradata Database resources by limiting
the number of sessions that it can control.
from an application is rejected.
If this command is not used, the maximum number of concurrent sessions that TDP will
allow is the same as the maximum number currently supported by the Teradata Database.
Unless IRF disabled, two internal sessions are established upon TDP startup that are used for
2PC. Establishing these sessions cannot be prevented by setting the MAXSESS number to 0.
These two internal sessions can only be disabled using the DISABLE IRF command, either by
entering it manually or including it in the TDPPARM data set.
Example
SET MAXS 25
Completion Message
TDP0544 TDP MAXIMUM SESSION LIMIT NOW SET TO: 25
203

SET STORAGE
SET STORAGE
Purpose
Changes the virtual storage limits used by TDP.
Syntax
SET STORAGE
CP nnnn
FE0CA048

where:
Syntax Element
Description
nnnn
Maximum number of bytes of virtual storage that will be used for CCUtype CP I/O
Usage Notes
If the SET STORAGE command is not used, TDP dynamically calculates the value, based on
the INITIAL CCU MAXBLKNM value and the number of started CPs. The minimum value,
which is determined by TDP, varies according to the number and types of CPs started, and the
values of INITIAL MAXBLKNM and MAXBLKSIZE. The maximum value that can be
specified is 4294967295, although this amount of storage may not actually be allocated. When
using INITIAL IOMODE EXCPVR or IOSDRIVR on z/OS, 31bit storage is used so the
dynamic calculations allow for more storage. For z/OS, use of INITIAL IOMODE EXCPVR or
IOSDRIVR results in CP virtual storage being fixed in real storage while it is allocated, so
allowing more storage can increase real storage utilization.
SET STORAGE overrides subsequent dynamic changes by TDP, and can prevent additional
CPs from being started. If the specified value is higher than the current maximum, any CP
waiting for buffers will immediately try again to obtain them.
Once SET STORAGE is invoked, there is no way to revert to dynamic calculation by TDP
without restarting TDP.
The current values can be displayed with the DISPLAY STORAGE command.
SET STORAGE is intended for use in consultation with Teradata Customer Support
personnel.
Example
SET STORAGE CP 2000000
204

SET USERCS
SET USERCS
Purpose
Establishes characteristics of a user-defined character set that is available on the Teradata
Database.
Syntax
SET USERCS
name
DDNAME
DD
ddn
FE0CQ101

Syntax Element
Description
name
Name of the user-defined character set on the Teradata Database.
ddn
z/OS or VOS3 JCL DD statement name in the TDP JCL that is associated with
a file that contains the character set attributes.
Usage Notes
This command does not create a new user-defined character set on the Teradata Database, it
only provides characteristics of such a user-defined character set that are needed by TDP.
The existence of the character set on the Teradata Database is not validated during execution
of the command. Such errors are reported if an attempt is made to use the character set.
Character sets supplied by the Teradata Database cannot be altered using this command. If the
specified character set name is that of a character set supplied by the Teradata Database, no
error will be generated but the definition will never be used; the standard definition will be
used.
If the character set name had been previously defined, that definition is replaced.
The DISPLAY USERCS command can be used to display the user defined character sets that
have been defined to TDP.
For more information on character sets, see Defining a Character Set on page 233.
Example
SET USERCS KOREAN_EBCDIC933 DDNAME TDPCS
Completion
TDP2832 KOREAN_EBCDIC933 HAS BEEN DEFINED
205

SET USERID
SET USERID
Purpose
Changes the Database userid that TDP uses to establish its internal sessions. The default value
for the TDP userid character set is EBCDIC.
Syntax
SET USERID name
FZAPB042

where:
Syntax Element
Description
name
Name of a database userid consisting of characters from the TDP character set,
specified by the SET CHARSET command.
When supported by the character set, you can include EBCDIC double-byte
characters if you:
Precede each contiguous group of characters with the Shift-out control
character, X0E, and
Follow the group with the Shift-in control character, X0F
The Database processes the userid characters left to right, even for character
sets normally associated with right to left languages such as Hebrew or Arabic.
Usage Notes
Unless this command is specified, TDPUSER is assumed. The specified name is used when
TDP internal sessions are next established (either when the CPs are initially started or as the
result of an ENABLE IRF command).
The current character set for the TDP userid can be displayed using the DISPLAY TDP
command.
The existence of the TDP character set in the database is not validated during the execution of
this command. Such errors are reported when the information is subsequently used in
attempting to establish TDP internal sessions. The specified userid must already exist in the
Database and have the following privileges:
206
SELECT on the DBC.InDoubtLog view
DELETE on the DBC.InDoubtLog view
EXECUTE on the DBC.TwoPCRule macro
With NULL Password

SET USERID
Example 1
SET USERID ANOTHERUSERID
Example 2
SET USERID TDPUSER
Completion Message
TDP0393 TDP USERID HAS BEEN SET TO name
Error Messages
Possible error messages are:
TDP0504
TDP0506
TDP0535
TDP0536
TDP0502
UNKNOWN TDP COMMAND NAME: text

UNKNOWN OPERAND TO THE SET COMMAND: text
TOO FEW OPERANDS FOR THE SET USERID COMMAND
TOO MANY OPERANDS FOR THE SET USERID COMMAND
LENGTH INCORRECT FOR SET USERID VALUE
207

SHUTDOWN
SHUTDOWN
Purpose
Stops TDP operation.
Syntax
SHUTDOWN
ORDERLY
O
CANCEL
QUICK
FZAPB045
Unlike other commands, the SHUTDOWN command has no abbreviation. Because the
impact of the command is irreversible, requiring it to be fully specified minimizes accidental
use.
where:
Syntax Element
Description
CANCEL
Cancels TDP immediately with a memory dump.
QUICK
Logs off all sessions before shutting down TDP.
ORDERLY
Disables logons and waits for sessions to end before shutting down
TDP.
This is the default.
Usage Notes
While this kind of
shutdown
is in progress . . .
You can execute SHUTDOWN with this option . . .
Orderly
QUICK or CANCEL
Quick
CANCEL
To obtain a dump in . . .
Use the command . . .
z/OS
z/OS DUMP (for an SVC dump), or z/OS CANCEL with the DUMP
argument.
VOS3
Note that an SVC dump is preferable.
208

SHUTDOWN
Example 1
SHUTDOWN CANCEL
Example 2
SHUTDOWN QUI
Completion Message
TDP510 QUICK SHUTDOWN REQUEST ACCEPTED
Example 1
SHUTDOWN O
Completion Message
TDP0510 ORDERLY SHUTDOWN REQUEST ACCEPTED
Example 1
SHUTDOWN
209

START CP
START CP
Purpose
Begins communication with the Teradata Database using a specified channel device.
Syntax
START
STA
cpname
CCU
CIC
2416A008
where:
Syntax Element
Description
cpname
Pair of database communication devices specified as CPnnnn, where nnnn is

the device number of the even-numbered IFP device. Either three or four
CCU
Specification that this CP requires a communication protocol known as the

Structure Protocol. All CPs using ESCON and CPs implemented by hardware
known as an EBCA have this requirement. This is the default.
CIC

Segment Protocol. All CPs for the DBC/1012 and CPs implemented by
hardware known as an MCA have this requirement.
Usage Notes
If an ATTACH CP command has not been issued previously, it is executed implicitly.
Before TDP will use the CP, a RUN command must be issued and complete.
The devices for an IFP can be either explicitly or dynamically allocated. Dynamic allocation by
TDP is the normal choice since only the START command is required. Explicit allocation
requires that the following be performed before the START command is issued:
If using this operating
system . . .
z/OS
VOS3
In the JCL procedure used to run TDP, include one DD statement for each
of the two devices for the CP. Each statement is in the form:
//CPnnn DD UNIT=nnn
In one DD statement the nnn is the even device number; for the other it is
the odd device number.
For four digit device numbers, z/OS requires that the UNIT parameter
contain a slash: UNIT=/nnnn
210

START CP
Example
START CPC308
Completion Message
The following message confirms that the command has been validated.
TDP1363 START COMMAND ACCEPTED FOR CPC308
The following message subsequently confirms that the command has been completed.
TDP1354 "CPC308" HAS BEEN STARTED
211

START IFP (Deprecated by the START CP command)
START IFP (Deprecated by the START CP

command)
Purpose
Causes TDP to begin communicating with a CP.
Syntax
START
STA
cpname
CIC
CCU
2416A012
where:
Syntax Element
Description
cpname
CP with which TDP is to communicate as IFPnnnn, where nnnn is the device

number of the even-numbered CP device, in three or four hexadecimal digits.
CIC

Segment Protocol. All CPs for the DBC/1012 and CPs implemented by
hardware known as an MCA have this requirement.
CCU

Structure Protocol. All CPs using ESCON and CPs implemented by hardware
known as an EBCA have this requirement.
Usage Notes
The START CP command must be executed for at least one CP before TDP can accept any
requests from applications.
Once executed, the START CP command initiates processing that implicitly ATTACHes
(establishes a logical and a physical attachment between) the CP to TDP, if the CP was not
previously ATTACHed
The devices for an CP can be either explicitly or dynamically allocated. Dynamic allocation is
the more usual operation since no explicit allocation is required: TDP automatically allocates
the required devices. Explicit allocation requires that the following be performed prior to
STARTing the CP:
212

START IFP (Deprecated by the START CP command)
If using this operating

system . . .
z/OS
Include two DD statements in the JCL procedure that is used to start TDP.
VOS3
The DD statements should be in this format:

//IFPnnnn DD UNIT=nnn
One of these statements is for the even CP device number, the other for the
corresponding odd CP device number.
If a four-digit device number is specified for the UNIT keyword, z/OS
requires that a slash precede the digits, as in UNIT=/nnnn
For either operating system, IFPnnnn corresponds to the cpname used in the START
command. IFPnnn and IFP0nnn are equivalent. That is, the command can specify one form
and the static system definition can specify the other.
If you issue the START CP command immediately after a STOP CP command, the CP must
complete the stop process before it can start again.
Example
STA IFP490
Completion Message
IFP490 SUCCESSFULLY STARTED
213

START POOL
START POOL
Purpose
Establishes and enables a session pool.
Session pools are not supported if the application provided any CLIv2 Workload specification
or used the Utility-workload DBCAREA option.
Session pools are not supported for utilities such as FastLoad, MultiLoad, Archive/Recovery,
and FastExport. Because utility programs use special internal run strings, they do not work
with session pools.
Syntax
START
STA
POOL
POO
DDNAME
filename
DD
A
number
NUMSESS
NUM
JOBNAME
jobname
JO
A
B
ID
runstring
RUN
RU
poolid
C
CHARSET
character_set_name
CH
C
D
NULLPSWD
session_attributes
NUL
D
LOGON
username
LO
,password
,' acctid '
FZAPC047
where:
Syntax Element
Description
filename
z/OS data set file, defined in the TDP startup procedure, that contains
START POOL commands.
If specified, it must be the only argument specified by the command.
number
Number of sessions that are to be established for the pool.

This is a required argument unless DDNAME is specified.
The deprecated specification FILE is equivalent to DDNAME.
214

START POOL
Syntax Element
Description
Number can be no larger than the maximum number of sessions
(MAXSESS) that has been set by the installation, or the session
capacity of the Teradata Database
jobname
Indication that the pool is restricted to a job named jobname. (You can
establish several pools with the same logon string, but with different
job names.)
runstring
Optional run string argument that is used when establishing pool

sessions.
The default is DBC/SQL. TEQUEL can also be specified.
poolid
Optional, unique identifier of up to eight alphanumeric characters

that identifies the pool.
If omitted, TDP assigns the pool an identifier in the form POOLnnnn,
where nnnn is an ascending number, beginning with 1.
character_set_name
Character set name with a maximum of 30 characters, to be used in

this pool for logons. Choose from the following, having EBCDIC
characteristics:
EBCDIC
EBCDIC037_0E
EBCDIC273_0E
EBCDIC277_0E
HANGULEBCDIC933_1II
KANJIEBCDIC5026_0I
KANJIEBCDIC5035_0I
KATAKANAEBCDIC
SCHEBCDIC935_2IJ
TCHEBCDIC937_3IB
Or one of the following, having ASCII characteristics:
215

START POOL
Syntax Element
Description
ARABIC1256_6A0
ASCII
CYRILLIC1251_2A0
HANGUL949_7R0
HANGULKSC5601_2R4
HEBREW1255_5A0
KANJIEUC_0U
KANJISJIS_0S
LATIN1_0A
LATIN1250_1A0
LATIN1252_0A
LATIN1252_3A0
LATIN1254_7A0
LATIN1258_8A0
LATIN9_0A
SCHGB2312_1T0
SCHINESE936_6R0
TCHBIG5_1R0
TCHINESE950_8R0
THAI874_4A0
UTF8
Or UTF16
Or any user-defined character set established using the TDP SET
USERCS command.
Although other names can be specified, their characteristics (the
codepoint for the space, comma, apostrophe, and quotation symbols;
the codepoints for control characters; the encoding scheme, and the
rules for monocasing) are assumed to be as for EBCDIC.
This character set also defines the characters that can be used in the
logon string of the LOGON operand. If omitted, the default TDP
character set is used to process this logon string.
Since the character set must be known prior to the interpretation of
the LOGON value, if CHARSET is needed it should precede LOGON
to ensure proper parsing. If CHARSET for other than the TDP default
character set follows LOGON, the command is not rejected but a
TDP2712 warning message is issued since the logon string can not be
properly interpreted, depending on the characteristics of the character
set.
NULLPSWD
Optional password in the logon string (specified by the LOGON

option).
This keyword enables the use of session pools for which TDP has
authenticated the Database userid.
216

START POOL
Syntax Element
Description
The deprecated specification NULLPWD is equivalent to
NULLPSWD.
session_attributes
List of available attributes for all sessions for this pool, as described
below.
If the Teradata Database does not support a specified attribute, the
pool does not start. If an attribute is not specified, but the Teradata
Database has been configured with a default attribute, the default is
used.
Attribute
Function
TWOPC
Causes TDP to establish all

sessions in the pool in 2PC
mode.
TERADATA
Indicates that Teradata

transaction semantics are to be
used.
This keyword is mutually
exclusive with the ANSI
keyword.
ANSI
Indicates that ANSI

transaction semantics are to be
used.
exclusive with the TERADATA
keyword.
DATEFORM
Indicates how dates are

processed by the Teradata
Database. DATEFORM values
are:
ANSI
Indicates that ANSI date
format is to be used.
TERADATA
Indicates that Teradata date
format is to be used.
217

START POOL
Syntax Element
Description
DEFAULT
Indicates that the Teradata
Database uses the default date
format associated with the
user/Teradata Database. Since
TDP does not know which
format the Teradata Database
will use when DEFAULT is
specified, only sessions that
also specify (or default to)
DEFAULT will use the pool.
If DATEFORM is omitted,
DATEFORM DEFAULT is
assumed.
SQL2
Generates a warning when

SQL not conforming with to
the FIPS 127-2 language
standard is used.
exclusive with the SQL3
keyword.
SQL3
Generates a warning when

SQL not conforming with to
the FIPS 127-3 language
standard is used.
exclusive with the SQL2
keyword.
STMTSTAT
Indicates the type of statement

status parcels to be returned by
the server. STMTSTAT values
are:
ORIGINAL - indicates that
Success and OK parcels are
returned.
ENHANCED - indicates
that ResultSummary
parcels are returned.
If STMTSTAT is omitted,
STMTSTAT ORIGINAL is
assumed.
username ,password
,acctid
logon string to be used to log the pool sessions on to the Teradata

Database.
The password is optional if the NULLPSWD option is also specified.
This argument is required unless DDNAME is specified.
218

START POOL
Syntax Element
Description
The userid, password, and account name each consist of characters
from the current TDP character set (SET CHARSET). When
supported by the current character set, EBCDIC double-byte
characters can be included by preceding each contiguous group of
them with the Shift-out control character, X0E, and following this
group with the Shift-in control character, X0F. Neither commas,
apostrophes, nor quotation marks can be specified as double-byte
characters.
The Database processes the logon string characters left to right, even
for character sets normally associated with right to left languages such
as Hebrew or Arabic.
If the TDP default character set is not appropriate for the logon string,
the proper character set must be specified by the CHARSET operand.
If CHARSET for other than the TDP default character set follows
LOGON, the command is not rejected but a TDP2712 warning
message is issued since the logon string may not be properly
interpreted, depending on the characteristics of the character set.
The deprecated specification STRING is equivalent to LOGON.
While the Teradata Database permits spaces outside apostrophes
before a comma in the logon string, they may not be present since
such spaces in TDP command syntax are delimiters and indicate the
end of the logon string. However, the presence of such spaces in the
logon string are ignored when comparing it to this logon string.
Usage Notes
A START POOL command is not processed by TDP until at least one START CP command
and the RUN command has been processed (that is, until at least one CP has been started).
Thus, if a START POOL command occurs in the TDP startup data set (TDPPARM) before
either of these commands, the START POOL command is not processed until a CP is attached
and started.
A START POOL command may not be processed for one of the following reasons:
The command contains syntax errors.
A pool having the same logon string (and jobname, if appropriate) already exists.
Logons are disabled.
The poolid argument of the command is not unique.
When a character set that is not valid is specified, the following message displays:
TDP2711 THE "CHARSET" VALUE IS NOT SUPPORTED
A START POOL command is rejected if a pool already exists with the same logon string JOB
specification and session attributes (TWOPC, ANSI/TERADATA, DATEFORM, SQL2/SQL3,
STMTSTAT).
219

START POOL
JOB Specification and Session Attributes

The JOB jobname and session attributes restriction is used to reserve pool sessions only for
application logon requests that are associated with the specified job and session attributes. If a
request matches the restriction of an established pool and the pool has no sessions available
(not in use) to satisfy the request, the request is rejected. This is true even if an unrestricted
pool (that is, one with no restriction) exists with the same logon string.
Any logon request that has the same logon string as an unrestricted pool can use sessions from
the pool, regardless of the job or address space of the application (provided, of course, that a
restricted pool for that job does not also exist).
To be considered a match, the logon string of the application must be identical to the logon
string of the pool. Specification of NULLPSWD does not affect comparison of the logon
strings.
If the user password is changed for a userid being used in a session pool, the userid can log on
to the Teradata Database with the old password while the session pool is active.
Use of DDNAME Option
It may be necessary to use the DDNAME filename specification of the START POOL
command and include the command in a data set (under z/OS or VOS3) that is accessed
during TDP startup in the following situations:
When a START POOL command exceeds the maximum length (128 characters) allowed
for a console command. Because a logon string can contain up to 278 bytes, including
commas, apostrophes, and quotation marks (a maximum of 92 bytes for each
specificationusername, password, account identifier), it is possible that the START
POOL command can exceed 128 characters.
When it is necessary to protect the security of a password that is used in the logon string of
a START POOL command.
TDP supports sequential files with fixed or varying length unspanned record formats and any
logical record length supported by the device/operating system. If the records are fixed 80byte
records, columns 73 through 80 are reserved for traditional sequence numbers and are
ignored; otherwise, the entire record is used. Records containing only blanks are ignored. If
the first non-blank characters of a record are /*, the record is considered a comment and
ignored. Commands can be continued onto multiple records using continuation characters. If
the last non-blank character is a minus sign, the minus sign is discarded and the command
continues with the first column of the next record. If the last non-blank character is a plus
sign, the plus sign is discarded and the command continues with the first non-blank column
of the next record. A command can be continued onto any number of records.
While all characters for all records are normally EBCDIC, the value of the LOGON option can
be in another character set. Care must be taken to ensure that the final byte of the logon string
appearing at the end of a command is not a value that could be taken as an EBCDIC
continuation character when no continuation is intended. To prevent this, a semicolon can be
added to the end of any command. The semicolon is discarded before the command is
processed.
220

START POOL
NULLPSWD indicates that Teradata Database can process logon requests for the sessions even
if they do not supply a password. This requires that the userid be GRANTed WITH NULL
PASSWORD authority on the Teradata Database. Refer to Security Administration. The DBC
userid always requires a password so NULLPSWD is effectively ignored for this userid.
Use of NULLPSWD Option
Understand that using NULLPSWD in conjunction with GRANTing WITH NULL
PASSWORD allows unrestricted access to that userid unless a TDPUAX or TDPLGUX exit is
provided to control use of this userid by other means that a password. If exits are used to
provide such control, should they be disabled, either explicitly by the DISABLE command, or
implicitly as a result of TDPLGUX ABENDing, access is unrestricted.
Completion Messages
When the START POOL command is accepted for processing by TDP, the following message
is displayed:
TDP0866 ADDING number SESSIONS TO POOL ID: poolid
When the START POOL command has been processed, the following message is displayed:
TDP0881 POOL ID: poolid IS NOW ENABLED
Example
The following example demonstrates how to set up session pools to be used by an application.
In this example, nine session pools are established for Accounts Receivable, Accounts Payable,
and Finance. These pools are accessed only via transactions from JOB CICS.
Under z/OS or VOS3, the following DD statements are added to the startup JCL for TDP:
.
.
.
//TDPPARM
//ACCTREC
//ACCTPAY
//FINANCE
.
.
.
DD
DD
DD
DD
DSN=DBC.TDPPARM,DISP=SHR
DSN=DBC.ACCTREC,DISP=SHR
DSN=DBC.ACCTPAY(POOLPARM),DISP=SHR
DSN=DBC.FINANCE(POOLPARM),DISP=SHR
The <dbcpfx>.TDPPARM data set and the TDPn TDPCMD fm file contain the following
commands:
ENABLE LOGONS
START CP6B0
START CP6B2
START POOL DDNAME ACCTREC
START POOL DDNAME ACCTPAY
START POOL DDNAME FINANCE
RUN
These commands are all echoed to the operator console. The commands contained in the data
sets or files that are identified by the ddnames or FILEDEFs referenced by the START POOL
commands are not echoed to the system console.
221

START POOL
The contents of ACCTREC (data set or file) are:

START POOL NUM 15 JOB CICS LOGON AR,MONEYIN
START POOL NUM 25 JOB CICS LOGON AR,MONEYIN,ACCT1
START POOL NUM 40 JOB CICS LOGON AR,MONEYIN,ACCT2
The contents of ACCTPAY (data set or file) are:

START POOL NUM 20 JOB CICS LOGON AP,MONEYOUT,ACCT1
The contents of FINANCE (data set or file) are:

START POOL NUM 2 JOB CICS LOGON FIN,SPENDIT,DEPT1
Note that these session pools are established only after CP6B0 andCP6B2 are started.
222

STOP CP
STOP CP
Purpose
Ends communication with the Teradata Database using a specified channel device.
Syntax
STOP
STO
cpname
2416A009
where:
Syntax Element
Description
cpname

the device number of the even-numbered IFP device. Either three or four
Usage Notes
The STOP CP command can be used only when the CP is STARTEed.
A STOP command for a CCU-type will complete only after a response is received for each
request active on that CP when the STOP command was executed.
A STOP command for a CIC-type CP will complete only after all sessions on the dependentSP logoff, which might require that some session pools be STOPped and IRF be DISABLEd
and re-ENABLEd.
Example
STOP CPC308
Completion Messages
TDP1363 STOP COMMAND ACCEPTED FOR CPC308
TDP1355 "CPC308" HAS BEEN STOPPED
223

STOP IFP (Deprecated by the STOP CP command)
STOP IFP (Deprecated by the STOP CP command)

Purpose
Causes TDP to stop communicating with an CP.
While the command completes immediately, the CP does not actually stop until all activity on
the CP ends. The status in a DISPLAY CP command indicates STOPPING until all sessions
end, and STOPPED thereafter.
Syntax
STOP
STO
cpname
2416A009
where:
Syntax Element
Description
cpname

device, in three or four hexadecimal digits.
Usage Notes
The purpose of the STOP IFP command is to stop an CP for servicing without shutting down
the TDP to which it is attached. It can also be used if an CP is to be detached from the current
TDP and then attached to another TDP. In this case, once the CP is stopped (logically
detached from the current TDP), it must be physically detached from the current TDP using
the DETACH CP command.
All activity on the CP must end before the CP stops. On some versions of the Teradata
Database, the CP stops when an active request completes. On other versions of the Teradata
Database, all sessions on SPs associated with the CP must end before the CP will stop. In the
latter case, in addition to application sessions, this includes any unassigned session pool
sessions and any TDP internal sessions. It may be necessary to stop relevant session pools
using the STOP POOL command and relevant TDP internal sessions using the DISABLE IRF
command. The START POOL and ENABLE IRF commands can then be used to restore the
necessary sessions.
Example
STO IFP490
Completion Messages
TDP1363 STOP IFP COMMAND ACCEPTED
After all activity has ended:

TDP0531 devicename SUCCESSFULLY STOPPED
224

STOP POOL
STOP POOL
Purpose
Ends one or more session pools in an orderly manner.
Syntax
STOP
STO
POOL
ID poolid
ALL
FZAPB049
where:
Syntax Element
Description
poolid
Unique identifier of the pool that is to be stopped.
ALL
Requests that all pools be stopped.
Usage Notes
The STOP POOL command does the following:
Disables logons to the pool(s) that are to be stopped.
Logs off pool sessions that are not in use.
Waits for any pool session that is in use to run until the application logs off. The session is
then logged off from the Teradata Database. When all pool sessions are logged off, the pool
is removed.
To terminate existing pool sessions without waiting for them to finish and disable the pools
(but not eliminate them), use the LOGOFF POOL command.
Example 1
STO POOL ID: ACTR04
Example 2
STO POOL ALL
Completion Messages
When the STOP POOL command is accepted for processing by TDP, the following message is
displayed:
TDP0867 STOPPING POOL ID poolid
When the STOP POOL command has been processed, the following message is displayed:
POOL ID: poolid IS NOW STOPPED
225

STOP POOL
226
APPENDIX A
Channel Processor Device and Channel

Error Log
This appendix contains details about the channel processor device and channel error log.
Sample EREP Record

Introduction
TDP logs CP unit and channel errors in hexadecimal format to an error log on the z/OS client.
Access and print the error log by using the appropriate error logging utility, such as the IBM
EREP utility for z/OS clients.
Figure 2 shows a sample record returned by EREP. The four-digit hexadecimal numbers in the
left-most column of the record are memory addresses.
The tables in the following subsections describe the format and contents of the EREP record
and the CSW sense byte:
Record Format For CPs That Require the CCU Operand in the START Command
Record Format For CPs That Do Not Require the CCU Operand in the START
Command
Sense Data For CPs That Require the CCU Operand in the START Command
Sense Data For CPs That Do Not Require the CCU Operand in the START Command
227
Appendix A: Channel Processor Device and Channel Error Log

Record Format
Figure 2: Sample EREP Record
RECORD TYPE UNKNOWN OR UNSUPPORTED

MODEL 4341
SERIAL NO- 014816
--- RECORD ENTRY SOURCE - OBR

VS 2 REL.
NONE
DAY YEAR
DATE- 107 60
JOB
HH MM SS.TH
TIME-15 34 08 72
IDENTITY- TDP3
FAILING CCW CSW
01 33 D0 E0 60 00 00 14
00 26 50 70 0E 00 00 14
DEVICE TYPE CODE- 300008D0

PRIMARY CUA 0005B0 SECONDARY CUA 0005B0
HEX DUMP OF RECORD
HEADER 30800800 00000000 0060107F 15340872 00014816 43410000
0018 E3C4D7F3 00000000 0133D0E0 60000014 00265070 0E000014 000005B0
300008D0
0038 000005B0 00001800 03000000 00000009 0FA00020 0000000B D2000101
00F10010
0058 0000
FZAPA090
Record Format
For CPs That Require the CCU Operand in the START Command
The following table provides the format and content of the EREP record for devices of a CP
that require the CCU operand on the START command:
228
Byte #
(Dec)
Content Description
Hexadecimal 30, indicating an Outboard record.
System-dependent operating system version.
Hexadecimal 08, indicating the time and date are as formatted by the TIME service,
plus a hexadecimal 10 if at least Extended Architecture.
Hexadecimal 40, indicating a temporary error.
Hexadecimal 80, indicating that no channel path is included.
57
Not used.
8 11
Date in packed decimal format.
12 15
Time in packed decimal format.
16 23
CPU identification.

Record Format
Byte #
(Dec)
Content Description
24 31
TDP jobname.
32 39
Channel Command Word (CCW) of the failing channel.
40 47
Channel Status Word (CSW) for 370 architecture.
48
Hexadecimal 03, indicating that three double words of device-dependent are available.
49
Not used.
50 & 51
Hexadecimal device number.
52 55
Hexadecimal device type, as defined to the system.
56 & 57
Not used.
58 & 59
Hexadecimal device number.
60 & 61
Not used.
62 & 63
Hexadecimal 0001, indicating the number of sense bytes present.
64 87
Device-dependent data, as follows:
88
Byte # (Dec)
Content Description
64 67
EBCDIC characters TRDT, identifying the product.
68
Hexadecimal 01, indicating the current level of the devicedependent data.
69
Hexadecimal S, indicating the Structure Protocol is being used.
70 & 71
Hexadecimal CP number.
72 79
EBCDIC TDPid.
80
Hexadecimal I/O completion code
81 87
Not used.
Sense byte.
If at least Extended Architecture, then:
Byte # (Dec)
Content Description
89 100
Extended Architecture Interrupt Response Block (IRB), which

contains the failing CSW.
101 104
Extended Status Word (ESW).
229

Record Format
For CPs That Do Not Require the CCU Operand in the START Command
The following table provides the format and content of the EREP record for devices of a CP
that do not require the CCU operand on the START command:
230
Byte #
(Dec)
Content Description
Class/Source of record
System/Release level
25
Record switches (not used)
Not used
Reserved
8 11
System date
12 15
System time
16
Machine version code
17 19
CPU serial number
20 & 21
CPU model (for example, 3033)
22 & 23
Not used
24 31
TDPid
32 39
Failing CCW
40 47
Content of CSW after I/O error
48
Count of double words that record uses for device-dependent data
49 51
Secondary control unit address associated with final retry of failing I/O device
52 55
Device type associated with failing device
57 59
Primary control unit address of device being used when failure occurred
60 & 61
Retry count
62 & 63
Number of bytes of sense data (24)
64 87
Sense data
88 & 89
Not used

Sense Data
Sense Data
For CPs That Require the CCU Operand in the START Command
The following table lists the sense bytes and device status bytes as returned in the CSW for
devices of CPs that require the CCU operand on the START command:
Sense
Byte
Status
Byte
Description
20
0E
Bus-out Check (hardware error)
10
0E
Equipment Check (device error)
08
0E
Data Check (software error)
For CPs That Do Not Require the CCU Operand in the START Command
The following table lists sense bytes 0 and 1, along with the corresponding device status byte
(in hexadecimal) as returned in the CSW for devices of CPs that do not require the CCU
operand on the START command:
Sense Byte
Status
Byte
Description
10
01
0E
CIC hardware error
08
05
0E
Bus/Tag in driver fault
80
06
0E
Illegal field id for dev 0
80
07
0E
Message header size error for dev 0
80
08
0E
Message count error for dev 0
80
09
0E
Message size error for dev 0
80
0C
0E
Odd byte xfer for dev 0
80
0D
0E
Input Queue empty for dev 0 write
80
0E
0E
Rewind for dev 0 without a Writekey
80
10
0E
Dev 1 read stopped before all the data was transferred
80
11
0E
Two consecutive dev 0 Writekeys
80
14
0E
Unrecognized command byte during Initial Selection sequence
20
19
0E
Bad parity on Command byte during Initial Selection or following a

Write operation
10
28
0D
CP did not respond to CIC interrupt in allotted time (1 second)
231

Sense Data
232
Sense Byte
Status
Byte
Description
00
30
22
IOP Startup byte
00
33
85
The CIC has gone from OFFLINE to ONLINE.
80
39
0E
Write operation exceeded maximum CIC local buffer length
80
43
0E
WriteCount specified a max block size too small for the Teradata
Database
80
44
0E
WriteKey block size greater than maximum allowed
APPENDIX B
Overview of SET USERCS
This appendix provides an overview of how character sets are defined that can be applied
using the SET USERCS command.
Defining a Character Set

The actual definition of the character set is contained in the file associated with the specified
DDNAME. Sequential files with fixed or varying length unspanned record formats are
supported.
If the records are fixed 80 byte records, columns 73 through 80 are reserved for traditional
sequence numbers and are ignored; otherwise, the entire record is used. Records containing
only blanks are ignored. If the first non-blank characters of a record are /*, the record is
considered a comment and ignored.
Statements can be continued onto multiple records using continuation characters. If the last
non-blank character is a minus sign, the minus sign is discarded and the statement continues
with the first column of the next record. If the last non-blank character is a plus sign, the plus
sign is discarded and the statement continues with the first non-blank column of the next
record. A statement can be continued onto any number of records. A semicolon can be added
to the end of any statement. The semicolon is discarded before the statement is processed.
Directives
Each statement contains a directive or is associated with a directive that identifies the purpose
of the statement. A directive is analogous to a command but different terminology is used to
prevent confusion with true TDP commands.
The following directives are supported:
Table 3: Directives
Directive
Function
CHAR
Defines the syntactic characters.
CHARSET
Explicitly begins a definition and possibly the encoding scheme.
END
Ends processing of records in the file.
233
Appendix B: Overview of SET USERCS

Directives
Table 3: Directives (continued)
Directive
Function
MONOCASE
Defines characters that have both lower and upper case.
SANITIZE
Defines valid characters for TDP messages sent using operating system facilities.
UNICODE
Defines the syntactic characters and characters that have both lower and upper
case.
A file describes one or more character sets, although only one description is used by each SET
USERCS command.
When multiple descriptions are present, each begins with a CHARSET directive and ends with
the next CHARSET directive, the END directive, or the last record in the file.
The CHAR, MONOCASE, SANITIZE, and UNICASE directives can appear in any order
within a description. If a CHAR, MONOCASE, SANITIZE, or UNICODE directive appears
before a CHARSET directive, then a character set description is implicitly begun -- in effect, a
CHARSET directive with no operands is assumed.
The following sections provide information and syntax diagrams for each directive. Refer to
Appendix D: How to Read the Syntax Diagrams, for additional information on syntax
diagrams.
234

CHAR
CHAR
The CHAR directive defines the syntactic characters of importance to TDP.
Syntax
CHAR SPACE xx
COMMA xx
COM xx
DBLQUOTE xx
DBL xx
APOSTROP xx
APO x
...
JCM_D001
Usage Notes
The length of each value is determined by the encoding scheme for the character set. For the
characters of interest to TDP, the length is always two except for UTF16 encoding, for which
the length is four. The CHAR directive can be specified more than once for each character set.
If the same character is defined more than once for a character set (either on a single CHAR
directive, on multiple CHAR directives, or on a CHAR and a UNICODE directive), the last
value is used. All four characters must be defined to form a complete character set description.
If no CHARSET directive precedes CHAR, then a character set description is implicitly begun
-- in effect, a CHARSET directive with no operands is assumed.
Example
Define the relevant syntactic characters for IBM Code Page 833.
CHAR SPACE 40 COMMA 6B APOSTROP 7D DBLQUOTE 7F
235

CHARSET
CHARSET
The CHARSET directive explicitly begins a definition and possibly the encoding scheme.
Syntax
CHARSET
CHARS
NAME
NAM
character_set_name
ENCODING
ENC
EBCDIC
E
IBMSOSI
I
ASCII
A
BIGFIVE
R
SJIS
S
UHC
EUC-CN
EUC-KR
T
EUC-JP
U
UTF8
UTF-16
2417C005
Usage Notes
NAME identifies the character set to which the description applies. The name may include a
standard suffix that defines the encoding scheme. The standard suffix consists of an
underscore, a number not relevant to CLIv2, the encoding character (A, E, I, R, S, T, or U),
and an optional character not relevant to CLIv2. Each suffix corresponds to an ENCODING
operand value:
E - EBCDIC
I - IBMSOSI
A - ASCII
R - BIGFIVE
S - SJIS
T - EUC-CN or EUC-KR
U - EUC-JP
ENCODING optionally identifies the encoding scheme for the character set. If omitted, the
character set must contain a standard suffix that indicates the encoding. If such a suffix exists,
then the encoding cannot be overridden using this operand. The following character sets are
available in TDP.
236

CHARSET
ENCODING
Meaning
Characteristics
EBCDIC
Extended Binary-CodedDecimal Interchange Code
Single-byte (EBCDIC) codepoints:

X'00' through X'FF'
IBMOSI
IBM Shift-out/Shift-in
Single-byte (EBCDIC) codepoints:

X'00' through X'FF'
Double-byte (EBDCIC) codepoints:
Shift-out (X'0E') through Shift-in (X'0E')
ASCII
American Standard Code for

Information Interchange
Single-byte (ASCII) codepoints:

X'00' through X'FF'
BIGFIVE
Big Five Plus

X'00' through X'80', and X'FF'
Double-byte (ASCII) codepoints:
X'81' through X'FE'
EUC-CN
Extended Unix Code - China

X'00' through X'7F'
X'80' through X'FF'
EUC-JP
Extended Unix Code - Japan

X'00' through X'8D'
X'90' through X'FF'
Single-shift1 (X'8E')
Triple-byte (ASCII) codepoints:
Single-shift2 (X'8F)'
EUC-KR
Extended Unix Code - Korea

X'00' through X'7F'
X'80' through X'FF'
SJIS
Shift-JIS (Japanese Industrial

Standard)

X'00' through X'80'
X'A0' through X'DF'
X'FD' through X'FF'
X'81' through X'9F'
X'E0' through X'FC'
237

CHARSET
ENCODING
Meaning
Characteristics
UHC
Unified Hangul Code

X'00' through X'80', and X'FF'
X'81' through X'FE'
UTF8
UCS (Universal Character Set)

Transformation Format 8-bit
Single-byte (Unicode) codepoints:

X'00' through X'7F'
Double-byte (Unicode) codepoints:
X'C0' through X'DF'
(Most) triple-byte (Unicode) codepoints:
X'E0' through X'FE'
Most four-byte codepoints (X'F0' through X'F4')
are not supported by Teradata Database.
UTF16
UCS (Universal Character Set)

Transformation Format- 16-bit
Single-byte (Unicode) codepoints:

X'0000' through X'D7FF'
X'E000' through X'FFFF'
Surrogates (four-byte codepoints that begin or
end with the two-byte codpoints X'D800'
through X'DBFF') are not supported by Teradata
Database.
When the NAME operand is specified, if this name does not match the character set name
specified on the SET USERCS command, this directive and all directives until the next
CHARSET directive are ignored. When the NAME operand is not specified, then this directive
is used, which implies that any subsequent CHARSET directives in the file will never be
processed since this one will always be used.
While all codepoints are reflected to and from Teradata Database, for character sets that allow
mixtures of single and multi-byte characters, only the single-byte characters are meaningful to
TDP.
Example
Begin definition for IBM Code Page 833, the single-byte component for IBM CCSID 933.
CHARSET NAME KOREAN_EBCDIC933 ENCODING IBMSOSI
238

END
END
The END directive ends processing of records in the file.
Syntax
END
JCM_D003
Usage Notes
Any remaining records in the file are not read.
Example
END
239

MONOCASE
MONOCASE
The MONOCASE directive optionally defines characters that have both lower and upper case.
If this information is not supplied, then no monocasing is performed.
Syntax
MONOCASE
MON
JCM_D004
Usage Notes
The actual monocase information is contained on statements that immediately follow the
MONOCASE directive. Each such statement has the following syntax:
target_codepoint1<-target_codepoint2>: data_codepoint ...
where:
Syntax Element
Function
target_cod epoint1
Specifies the first character defined on this statement.
target_codepoint2
Optionally specifies the last character defined on this statement.
data_codepoint
Defines the upper case equivalent for the associated target_codepoint

character.
A codepoint is the hexadecimal representation of a character. The number of characters

needed to specify a codepoint is dependent on the encoding scheme for the character set. With
the current TDP support, the length is always two except for UTF16 encoding, for which the
length is four.
If the second target codepoint is specified, then one data codepoint is required for each
character in the range between the two target codepoints. If the second target codepoint is
omitted, then any number of data codepoints can be specified, each associated with codepoint
one greater than the previous.
All statements after the MONOCASE directive that contain a colon are associated with the
MONOCASE directive. Lack of a colon indicates that the statement is a new directive and
ends that MONOCASE directive.
The only codepoints that need be specified are those for which upper case equivalents exist.
The MONOCASE directive can be specified only once for each character set.
The order of data codepoints among different statements is not significant.
240

MONOCASE
If the same character is defined more than once for a character set (either on a MONOCASE
directive, or on a MONOCASE and a UNICODE directive), the last value is used.
If no CHARSET directive precedes MONOCASE, then a character set description is implicitly
begun -- in effect, a CHARSET directive with no operands is assumed.
Example
Define the monocase information for IBM Code Page 833, the single-byte component for
IBM CCSID 933.
MONOCASE
81-89: C1
91-99: D1
A2-A9: E2
241

SANITIZE
SANITIZE
The SANITIZE directive optionally defines valid characters for TDP messages sent using
operating system facilities. Since all such facilities support only EBCDIC, the sanitizing
process ensures that unsupported or non-EBCDIC characters are replaced by an acceptable
character (the Hyphen character (hexadecimal 60) is the TDP convention). If this information
is not supplied, then a default is chosen based on the encoding scheme.
Syntax
SANITIZE
SAN
JCM_D005
Usage Notes
The actual sanitize information is contained on statements that immediately follow the
SANITIZE directive. Each such statement has the following syntax:
where:
Syntax Element
Function
target_codepoint1
Specifies the first character defined on this statement
target_codepoint2
Optionally specifies the last character defined on this statement, and

data_codepoint defines the replacement character for the associated
target_codepoint character.

needed to specify a codepoint is dependent on the encoding scheme for the character set. For
the characters of interest to TDP, the length is always two except for UTF16 encoding, for
which the length is four.
All statements after the SANITIZE directive that contain a colon are associated with the
SANITIZE directive. Lack of a colon indicates that the statement is a new directive and ends
that SANITIZE directive.
The SANITIZE directive can be specified only once for each character set.
242

SANITIZE
The order of data codepoints among different statements is not significant. If the same
character is defined more than once for a character set, the last value is used.
If no CHARSET directive precedes SANITIZE, then a character set description is implicitly
Example
Provide the sanitize information for IBM Code Page 833, the single-byte component for IBM
CCSID 933. The valid characters which do not correspond to standard EBCDIC are converted
to Hyphens
SANITIZE
0E-0F: 4C
42-49: 60
52-59: 60
62-69: 60
72-78: 60
8A-8F: 60
9A-9F: 60
AA-AF: 60
B2: 60
BA-BC: 60
E0: 60
6E
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60 60
60 60
60 60
60
60 60
243

UNICODE
UNICODE
The UNICODE directive defines the syntactic characters and characters that have both lower
and upper case. It may be possible to use it to provide the same information as the CHAR and
MONOCASE directives. Since UNICODE is required to add a user-defined character set to
CLIv2, it is also supported by TDP to potentially simplify use of user-defined character sets.
The relevant syntactic characters in the character set are those that have the Unicode
codepoints of 0020 (Space), 0022 (Quotation Mark), 0027, (Apostrophe), and 002C
(Comma). The monocase information in the character set are those that have the Unicode
codepoints of 0061 through 007A (lower case) and 0041 through 005A (upper case).
Codepoints beyond those relevant to CHAR and MONOCASE are ignored. If these are not
the characteristics of the character set, then CHAR and MONOCASE must be used instead of
UNICODE.
Syntax
UNICODE
UNI
JCM_D006
Usage Notes
The actual information is contained on statements that immediately follow the UNICODE
directive. Each such statement has the following syntax:
where:
Syntax Element
Function
target_codepoint1
Specifies the first character in the user-defined character set that is defined
on this statement.
target_codepoint2
Optionally specifies the last character defined on this statement, and

data_codepoint defines the equivalent character in Unicode.

needed to specify a target codepoint is dependent on the encoding scheme for the character
set. For the characters of interest to TDP, the length is always two except for UTF16 encoding,
for which the length is four. The length of a data codepoint is always four.
244

UNICODE
All statements after the UNICODE directive that contain a colon are associated with the
UNICODE directive. Lack of a colon indicates that the statement is a new directive and ends
that UNICODE directive.
The order of data codepoints among different statements is not significant.
The UNICODE directive can be specified only once for each character set.
If the same character is defined for the same purpose more than once for a character set
(either on a CHAR directive, on a MONOCASE directive, or on a UNICODE directive), the
last value is used.
If no CHARSET directive precedes UNICODE, then a character set description is implicitly
Example
Define the Unicode equivalents for IBM Code Page 833, the single-byte component for IBM
CCSID 933.
UNICODE
40-47: 0020
48-4F: 11AD
50-57: 0026
58-5F: 11B4
60-67: 002D
68-6F: 110A
70-77: 005B
78-7F: 1112
80-87: 005D
88-8F: 0068
90-97: 001A
98-9F: 0071
A0-A7: 00AF
A8-AF: 0079
B0-B7: 005E
B8-BF: 001A
C0-C7: 007B
C8-CF: 0048
D0-D7: 007D
D8-DF: 0051
E0-E7: 20A9
E8-EF: 0059
F0-F7: 0030
F8-FF: 0038
001A
1103
001A
11B5
002F
110B
001A
0060
0061
0069
006A
0072
007E
007A
001A
001A
0041
0049
004A
0052
001A
005A
0031
0039
115F
00A2
1104
0021
11B6
00A6
110C
003A
0062
1161
006B
1167
0073
116D
005C
1173
0042
001A
004B
001A
0053
001A
0032
001A
1100
002E
1105
0024
1106
002C
110D
0023
0063
1162
006C
1168
0074
116E
001A
1174
0043
001A
004C
001A
0054
001A
0033
001A
1101
003C
11B0
002A
1107
0025
110E
0040
0064
1163
006D
1169
0075
116F
001A
1175
0044
001A
004D
001A
0055
001A
0034
001A
1115
0028
11B1
0029
1108
005F
110F
0027
0065
1164
006E
116A
0076
1170
001A
001A
0045
001A
004E
001A
0056
001A
0035
001A
1102
002B
11B2
003B
1121
003E
1110
003D
0066
1165
006F
116B
0077
1171
001A
001A
0046
001A
004F
001A
0057
001A
0036
001A
11AC
007C
11B3
00AC
1109
003F
1111
0022
0067
1166
0070
116C
0078
1172
001A
001A
0047
001A
0050
001A
0058
001A
0037
001A
245

UNICODE
246
APPENDIX C
Parcel Flavors
This appendix contains details about parcel flavors.
Parcel Structure
A parcel is a discrete physical unit of information transferred between TDP and the Teradata
Database. It consists of two parts: the header and the body, which can be null.
Body
Header
GQ02J014
Parcel Header
There are two formats of parcel headers. Definitions for the parcel headers are located on a
release tape as shown below:
For this language . . .
Definitions are located in the. . .
IBM Assembler
TDPXPH in library SAMPLIB (z/OS)
Flag
The first format is:
Flavor
Length
GQ02J015
Table 4: Original Parcel Header (TPH0)
Field Name
Offset
Length
Description
PH0FLAVR
00
1 bit
A binary zero, indicating this header format. The

mnemonic for the bit is PH0FALT
PH0FLAVR
0.1
15 bits
An unsigned integer identifying the type of parcel body.
247
Appendix C: Parcel Flavors

Parcel Flavors
Table 4: Original Parcel Header (TPH0) (continued)
Field Name
Offset
Length
Description
PH0LEN
02
2 bytes
An unsigned integer specifying the length of the parcel, in

bytes, including the parcel header and any body.
Flag
The second format is:
Unused
Flavor
Length
GQ02J016
Table 5: Alternate Parcel Header (TPH1)
Field Name
Offset
Length
Description
PH1FLAVR
00
1 bit
A binary zero, indicating this header format. The

mnemonic for the bit is PH1FALT
PH1FLAVR
0.1
15 bits
An unsigned integer identifying the type of parcel body.
PH1FILL1
02
2 bytes
Not used: Set to binary zeroes.
PH1LEN
04
4 bytes
An unsigned integer specifying the length of the parcel, in

bytes, including the parcel header and any body.
A response will only contain a parcel with the enlarged header if the APH-response-permitted
option was specified and the Teradata server supports the alternate header for that parcel.
Furthermore, parcels whose length is less than or equal to 65535 can use either header format.
Parcel Flavors
Definitions for the parcel flavors and content of the body headers are located on a release tape
as shown below:
For this language . . .
Definitions are located in the. . .
IBM Assembler
TRDSPB in library SAMPLIB (z/OS)
Table 6 provides the flavor number and name of the parcelsused by CLIv2 or CLIv2
applications.
248

Parcel Flavors
Table 6: Parcel Flavors
Flavor
Parcel Name
Flavor
Parcel Name
Req
RunStartup
Data
Respond
KeepRespond
Cancel
Success
Failure
10
Record
11
EndStatement
12
EndRequest
13
FMReq
14
FMRunStartup
17
Ok
18
Field
19
NullField
20
TitleStart
21
TitleEnd
22
FormatStart
23
FormatEnd
24
SizeStart
25
SizeEnd
26
Size
27
RecStart
28
RecEnd
31
Rewind
32
NOP
33
With
34
Position
35
EndWith
36
Logon
37
Logoff
38
Run
46
PosStart
47
PosEnd
49
Error
68
IndicData
69
IndicReq
71
DataInfo
72
IVRunStartup
85
Options
86
PrepInfo
88
Connect
114
SessionOptions
115
VoteRequest
116
VoteTerm
117
Cmmt2PC
118
Abrt2PC
120
CursorHost
121
CursorDBC
122
Flagger
125
PrepInfoX
128
Multi-TSR
129
SP options
136
UserNameRequest
137
UserNameResponse
140
MultipartData
141
EndMultipartData
249

Parcel Types
Table 6: Parcel Flavors (continued)
Flavor
Parcel Name
Flavor
Parcel Name
142
MultipartIndicData
143
EndMultipartIndicData
144
MultipartRecord
145
EndMultipartRecord
146
DataInfoX
147
MultipartRunStartup
148
MultipartReq
150
ElicitData
151
ElicitFile
152
ElicitDataReceived
153
ExtendedRespond
154
ExtendedKeepRespond
157
Keep-Position
158
RowPosition
159
OffsetPosition
164
ErrorInformation
169
StatementInformation
170
StatementInformationEnd
171
Result_summary
172
ResultSet
175
ResultSetCursor
178
Elicit Name
179
ResultSetSelection
189
ClientAttributes
190
FetchRowCount
192
StatementError
Parcel Types
There are two parcel types:
Request which are sent to the Teradata Database
Response which are sent from the Teradata Database
The two parcel types are described below
Request Parcels: Overview

Table 7 lists the request parcels by flavor, name, and use.
Table 7: Request Parcel Flavors, Names, and Uses
250
Flavor
Parcel Name
Use
1*
Req
Initiates a request (Record Mode).
RunStartup
Executes the users startup request (Record Mode).
3*
Data
Contains data for a Teradata SQL request (Record Mode).
4*
Respond
Requests a portion of Teradata SQL response.

Parcel Types
Table 7: Request Parcel Flavors, Names, and Uses (continued)
Flavor
Parcel Name
Use
5*
KeepRespond
Requests a portion of Teradata SQL response without

discarding response.
Cancel
Discards Teradata SQL response and closes Teradata SQL

request; discards those segments of a segmented data
request that have already been sent.
13*
FMReq
Initiates a request (Field Mode).
14
FMRunStartup
Executes the users startup request (Field Mode).
31
Rewind
Positions spool file pointer to beginning of the spool file.
32
NOP
Performs no operation.
36
Logon
Establishes a session.
37
Logoff
Terminates a session.
38
Run
Connects to the specified partition (for DBC/1012),

Applications Processor (for 3600), or node (for SMP/MPP
platforms).
68*
IndicData
Contains data for a Teradata SQL request (Indicator Mode).
69*
IndicReq
Initiates a request (Indicator Mode).
71*
DataInfo
Sends description of whichever data parcel follows it.
72
IVRunStartup
Executes the users startup request (Indicator Mode).
85*
Options
Specifies which PREPARE options are used when a request

is sent to the Teradata Database.
88*
Connect
Connects to the specified partition (for DBC/1012),

Applications Processor (for 3600), or node (for SMP/MPP
platforms).
114
SessionOptions
Session options.
115
VoteRequest
Requests a 2PC vote.
116
VoteTerm
Requests commitment of the current 2PC transaction and

returns a vote.
117
Cmmt2PC
Requests commitment of the current 2PC in-doubt

transaction.
118
Abrt2PC
Aborts the current 2PC transaction.
120*
CursorHost
Provides cursor information.
128
Multi-TSR
Provides segments of a request that is too large to fit into

the maximum parcel size. This parcel is currently only used
for the text of Stored Procedures.
136
UserNameRequest
Requests return of the userid assigned to the session.
251

Parcel Types
Table 7: Request Parcel Flavors, Names, and Uses (continued)
Flavor
Parcel Name
Use
137
UserNameResponse
Returns the userid assigned to the session.
140*
MultipartData
Contains data for an SQL request (Multipart mode).
141*
EndMultipartData
End of data for a request (Multipart mode).
142*
MultipartIndicData
Contains data for an SQL request (Multipart Indicator

mode).
143*
EndMultipartIndicData
End of data for a request (Multipart Indicator mode).
146*
DataInfoX
Sends description of subsequent data parcels (Multipart

mode).
147*
MultipartRunStartup
Executes the user's startup request (Multipart mode).
148*
MultipartReq
Initiates a request (Multipart mode).
153*
ExtendedRespond
Requests a portion of Teradata SQL response.
154*
ExtendedKeepRespond
Requests a portion of Teradata SQL response without

discarding response.
157
KeepPosition
Requests that information be retained in the Teradata SQL

response to allow positioning to a specified position.
158
RowPosition
Requests that the Teradata SQL response be repositioned to

a specified row.
159
OffsetPosition
Requests that the Teradata SQL response returning a single

Large-object selected by a Locator be repositioned to a
specified byte or character offset.
169
Describes the data items contained in the request when

those attributes are not otherwise known.
170
StatementInformationEnd
Delimits StatementInformation parcels in the request.
175
ResultSetCursor
Identifies the row last fetched by an External Stored

Procedure for a response being propagated to the caller or
application.
178*
Elicit Name
Indicates that data must be supplied.
179
ResultSetSelection
Indentifies which statement responses to a request from

and External Stored Procedure will be propagated to the
caller or application.
189
ClientAttributes
Provides descriptive information when establishing a

session.
190*
FetchRowCount
Specifies the maximum number of rows returned by the

Database in a response buffer.
* Parcel is described in Teradata Call-Level Interface Version 2 Reference for Mainframe-Attached

Systems.
252

Parcel Types
Response Parcels: Overview

Table 8 following table lists the response parcels by flavor, name, and use.
Table 8: Response Parcel Flavors, Names, and Uses
Flavor
Parcel Name
Use
Success
Indicates that the specified Teradata SQL statement completed

successfully in other than Field Response-mode when using
Original Statement-status.
Failure
Indicates that the specified statement has failed and the entire
transaction was rolled back.
10
Record
Returns one row of selected results.
(Record Mode)
10
Record
Returns one row of selected results.
(Indicator Mode)
11
EndStatement
Delimits the end of the results from the specified Teradata SQL
statement.
12
EndRequest
Delimits the end of a Teradata SQL response to a Teradata SQL

request.
17
Ok

successfully in Field Response-mode when using Original
Statement-status.
18
Field
Contains returned information (data value, title, format, or

echo).
19
NullField
Returns a null data value for a field.
20
TitleStart
Delimits the start of a set of Title parcels.
21
TitleEnd
Delimits the end of a set of Title parcels.
22
FormatStart
Delimits the start of a set of format-containing Field parcels.
23
FormatEnd
Delimits the end of a set of format-containing Field parcels.
24
SizeStart
Delimits the start of a set of Size parcels.
25
SizeEnd
Delimits the end of a set of Size parcels.
26
Size
Specifies the width of a column of selected results.
27*
RecStart
Delimits the start of a set of data-value-containing Field and

Null-Field parcels or a set of echoed string- containing Field
parcels.
28*
RecEnd
Delimits the end of a set of data-value-containing Field and

Null-Field parcels or a set of echoed string-containing Field
parcels.
253

Parcel Types
Table 8: Response Parcel Flavors, Names, and Uses (continued)
254
Flavor
Parcel Name
Use
33*
With
Delimits the start of a set of parcels for the specified WITH

clause.
34*
Position
Specifies the column number being summarized.
35*
EndWith
Delimits the end of a set of parcels for the specified WITH clause.
46*
PosStart
Delimits the start of a set of Position parcels.
47*
PosEnd
Delimits the end of a set of Position parcels.
49*
Error
Indicates that the specified statement has an error not serious

enough to cause rollback.
71*
DataInfo
Returns a description of the following Indicator Mode Record

parcels.
86*
PrepInfo
Returns column information from the Teradata Database when a

Teradata SQL statement has been sent with a Request Processing
Option of Prepare and a Response Mode of Indicator.
121*
CursorDBC
Returns cursor information.
122*
Flagger
Returns language non-conformances.
125*
PrepInfoX
Returns column information from the Teradata Database when a

Teradata SQL statement has been sent with a Request Processing
Option of Prepare and a Response Mode of Extended.
137
UserNameResponse
Returns the userid assigned to the session.
144*
MultipartRecord
Returns selected results (Multipart mode).
145*
EndMultipartRecord
Indicates end of selected results for one row (Multipart mode).
146*
DataInfoX
Returns a description of subsequent parcels (Multipart mode).
150*
ElicitData
151*
ElicitFile
Indicates that the contents of a file must be supplied.
152*
ElicitDataReceived
Indicates that elicited data was received by the Teradata Database.
164
ErrorInformation
After an Error parcel (flavor 49), provides additional information

about the error.
169
Returns a description of the data, when the Options parcel

(flavor 85 in Table 7) specifies Return-statement-info
(corresponding to the CLIv2 DBCAREA Return-statement-info
option)
170
Statement
InformationEnd
Delimits related StatementInformation parcels.
171
ResultSummary

successfully when using Enhanced Statement-status.

Parcel Descriptions
Table 8: Response Parcel Flavors, Names, and Uses (continued)
Flavor
Parcel Name
Use
172
ResultSet
Introduce parcels returned from a CALLed stored procedure
178*
ElicitName
192*
StatementError
Indicates a statement in a multi-statement request encountered a

problem but the transaction is not rolled back.
* Parcel is described in Teradata Call-Level Interface Version 2 Reference for Mainframe-Attached

Systems.
Parcel Descriptions
This section describes the following parcels generated by user applications and the Teradata
Database.
Abrt2PC
Cancel
Client Attributes
Connect
Cmmt2PC
FMRunStartup
IVRunStartup
Logoff
Logon
Multi-TSR
NOP
OffsetPosition
ResultSet
ResultSet Cursor
Rewind
RowPosition
Run
RunStartup
SessionOptions
UserNameRequest
UserNameResponse
VoteRequest
VoteTerm
Abrt2PC
Purpose
The Abrt2PC parcel aborts the current transaction for a 2PC session. CLIv2 creates this parcel
at the direction of the coordinator. The parcel can be submitted whenever there is an open
transaction.
255

Cancel
Usage Notes
Use of this parcel requires Teradata Database for UNIX version 2 release 2 (or later), or
Teradata DBS for TOS version 1 release 5 (or later).
An Error parcel is returned if there is no open transaction.
A Failure parcel is returned if the session is not in 2PC mode.
The successful response is a Failure parcel.
Parcel Data
Table 9 lists field information for Abrt2PC Parcel.
Table 9: Abrt2PC Parcel Field Information
Flavor
Parcel
Body
Length
Parcel Body Fields
118
none
Cancel
Purpose
The Cancel parcel terminates Teradata Database output for the request, or cancels segments of
request data previously sent.
Usage Notes
The parcel is generated by CLIv2 at the direction of the application.
When used to terminate Teradata Database output, this parcel deletes spool files that contain
the results of a Teradata request. The response is an End Request parcel.
When used to cancel segments of a request, this parcel deletes segments that were previously
received by the Teradata Database. The response is a Failure parcel.
Parcel Data
Table 10 lists field information for the Cancel parcel.
Table 10: Cancel Parcel Filed Information
256
Flavor Field
Body Parcel
Length
Parcel Body Fields
none

ClientAttributes
ClientAttributes
Purpose
Provides descriptive information when establishing a session.
Table 11: ClientAttributes Parcel Information
TRDSPBCA
Flavor Field
Mnemonic
189
TRDSPFCA
Field
Length
Value
PBCAID
2 byte unsigned integer
An attribute id
PBCALEN
2 byte unsigned integer
Length of the attribute

data
From one to three attributes may be defined, each beginning with the PBCAID and
PNCALEN fields described above.
Table 12: Character Attributes
TRDSAACX
Field
Length
Value
PBCACXH
4 bytes
The two 2byte integer fields

PBCAID and PBCALEN as
described above
PBCACXC
1 byte hexadecimal
The character set code for the

subsequent text, always X'C0'
PBCACXTX
The number of bytes less one

contained in the PBCALEN field
The EBCDIC value for the

attribute
The following three attributes are defined.

Table 13: Attributes
Attribute id
Mnemonic
Value
24
PBCAI2R
CLIv2 release
25
PBCAID
Any session description specified by

the application using the DBCAREA
SESSION-DESC operands
26
PBCAIAW
Any workload description specified

by the application using the
DBCAREA WORKLOAD operands
257

Cmmt2PC
Cmmt2PC
Purpose
The Cmmt2PC parcel commits the current in-doubt transaction for a 2PC session.
Usage Notes
Teradata Database for UNIX version 2 release 2 (or later), or Teradata DBS for TOS version 1
release 5 (or later) is required to use this parcel.
CLIv2 creates this parcel at the direction of the coordinator.
Submit the Cmmt2PC parcel after a Success response has been returned for a VoteRequest
parcel.
The return results are as follows:
An Error parcel is returned if there is no transaction open for the session.
A Failure parcel is returned if the current transaction is:
Not in-doubt
Not in 2PC mode
A Success parcel is returned if none of the conditions above are true.
Parcel Data
Table 14 lists field information for Cmmt2PC.
Table 14: Cmmt2PC Parcel Field Information
Flavor Field
Body Parcel
Length
Parcel Body Fields
117
none
Connect
Purpose
The Connect parcel establishes a connection between an application and a specific Database
partition that is used for running Teradata SQL.
Usage Notes
The Connect parcel is sent from the client at the same time that a Logon parcel is sent.
This parcel is generated by CLIv2 on behalf of the application.
The response to a Connect parcel is first a Success parcel and then a RunResponse parcel.
258

FMRunStartup
Parcel Data
Lists field information for the Connect parcel.
Flavor Field
Body Parcel Length
Parcel Body Fields
88
24
PartitionName: 16 bytes
LogonSequence Number: 4 bytes
Function: 2 bytes
Pad: 2 bytes
Fields
PartitionName is the name of the Database partition to which start requests are to be sent.
LogonSequenceNumber contains a logon sequence number when Function contains the

value 2. At all other times it must contain zero.
Function contains one of the following:
Function Number
Description
Requests that a normal Run be performed.
Requests session control allocate a logon sequence number and associate the
newly allocated logon sequence number with the requesting session.
Requests session control to associate the logon sequence number in logon

sequence number with requesting session.
Pad is unused.
FMRunStartup
Purpose
The FMRunStartup parcel executes the users Startup request and returns the results in Field
Mode.
Usage Notes
This parcel is generated by CLIv2 at the direction of the application.
If a startup request is not stored with the data base, the response is an Error parcel with error
code 3747.
Parcel Data
Table 15 provides field information for the FMRunStartup parcel
259

IVRunStartup
Table 15: FMRunStartup parcel Field Information
Flavor Field
Body Parcel
Length
Parcel Body Fields
14
none
IVRunStartup
Purpose
The IVRunStartup (Indicator Mode Run Startup) parcel executes the users startup request
and returns the results in Indicator Mode. If a startup request is not stored with the Teradata
Database, the response parcel is an Error parcel with error code 3747.
Usage Notes
This parcel is generated by CLI at the direction of the application.
Parcel Data
Table 16 provides field information for the IVRunStartup parcel.
Table 16: IVRunStartup Parcel Field Information
Flavor Field
Parcel Body
Length
Parcel Body Fields
72
none
Logoff
Purpose
The Logoff parcel terminates the session.
Usage Notes
Parcel Data
Table 17 provides field information for the Logoff parcel.
260

Logon
Table 17: Logoff Parcel Parcel Field Information
Flavor Field
Parcel Body
Length
Parcel Body Fields
37
none
Logon
Purpose
Establishes a session if the userid and password are valid
Usage Notes
If an account is not supplied, the default account for the user is used.
Parcel Data
Table 18 provides field information for the Logon parcel.
Table 18: Logon Parcel Field Information
Flavor Field
Body Parcel
Length
Parcel Body Fields
36
1 to 6916
LogonString:
1 to 6916
Field Notes
LogonString is a character string containing the following elements:
userid, password[, account]
where
The userid is the users identification. It must consist of at least one character and can consist
of as many as 6916characters. Each character may require 1, 2, or 3 bytes, depending on the
character set used. The userid can be enclosed in apostrophes, each of which requires 1 byte (2
bytes if Unicode).
Note that SQL terminal symbols (such as apostrophes) must always come from the shortest
repertoire; that is 1 byte. Terminal symbols are never 3 bytes.
The userid and password must be separated by a comma.
The password is the users password. It must consist of at least one character, and can consist
of as many as 6916 characters. Each character may require 1, 2, or 3 bytes, depending on the
character set used. The password can be enclosed in quotation marks, each of which requires 1
byte (2 bytes if Unicode).
261

Multi-TSR
Note that SQL terminal symbols (such as quotation marks) must always come from the
shortest repertoire; that is 1 byte. Terminal symbols are never 3 bytes.
If the account is not omitted, the password and account must be separated by a comma.
The userid, password, and account name each consists of characters from the session
character set.
When supported by the session character set, double-byte characters can be included by
preceding each contiguous group of them with the Shift-out control character, X0E, and
following this group with the Shift-in control character, X0F.
Neither commas nor blanks can be specified as double-byte characters.
Note: The password is usually required, but it may be optional in the logon string submitted
by the application if the site has an exit routine that validates the userid.
The account (optional) is the account under which the user is logging on. The account can
consist of as many as 6916 characters, and it must be enclosed in apostrophes. Any apostrophe
in the account name must be represented by two apostrophes. The second apostrophe is not
counted toward the limit of 6916 characters. Each character may consist of 1, 2, or 3 bytes,
depending on the character set used. If the account string consists of 6916 apostrophes, and is
encoded in Unicode (2-byte terminal symbols), 124 bytes are necessary to specify the field.
The userid and password must satisfy the lexical characteristics of Teradata SQL words.
See the description of lexical characteristics in SQL Fundamentals or Database Design.
Multi-TSR
Purpose
Provides segments of a request that is too large to fit into the maximum parcel size. This parcel
is currently only used for the text of Stored Procedures.
Usage Notes
This parcel is generated by CLIv2 when the Segment Data option is specified by the
application.
Parcel Data
Table 19 provides field information for the Multi-TSR parcel.
Table 19: Multi-TSR Parcel Field Information
262
Flavor
Parcel Body
Length
128
Parcel Body Fields

SequenceNumber: 2 bytes
Status: 1 byte

NOP
Field Notes
The SequenceNumber field specifies the order of the segment, relative to other segments.
SequenceNumber is a binary value that begins at one and increments by one for each MultiTSR parcel.
The Status field specifies the type of segment. A binary one indicates that this is the last
segment. Otherwise the value is a binary zero.
NOP
Purpose
The Teradata Database will discard this parcel without taking any action.
Parcel Data
Table 20 provides field information for the NOP parcel.
Table 20: NOP Parcel Field Information
Flavor Field
32
Parcel Body
Length
0 to maximum
parcel size
Parcel Body Fields

0 to maximum parcel size
OffsetPosition
Purpose
The OffsetPosition parcel requests that the Teradata SQL response returning a single Largeobject selected by a Locator be repositioned to a specified BLOB byte offset or CLOB character
offset.
Usage Notes
OffsetPosition is included in a Continue request to reposition to a particular byte in a
Largeobject.
If present, the OffsetPosition parcel must immediately precede either the
ExtendedKeepRespond or KeepRespond parcel.
Parcel Data
Table 21 provides field information for the OffsetPosition parcel.
263

ResultSet
Table 21: OffsetPosition Parcel Field Information
Parcel Flavor
Parcel Body
Length
Parcel Body Fields
159
12
Statement Number : 2 bytes

Unused : 2 bytes
Offset : 8 bytes
ResultSet
Purpose
The ResultSet parcel is returned after a Success, OK, or ResultSummary parcel to introduce
parcels returned from a CALLed stored procedure when Result-sets-OK 'Y' was specified
(corresponding to the Options parcel (flavor 85) DynamicResultSets 'Y' option).
Parcel Data
Table 22 provides field information for the ResultSet parcel.
Table 22: ResultSet Parcel Field Information
TRDSPBRT
Flavor
Mnemonic
172
TRDSPFRT
Field
Length
Value
PBRTRNUM
8byte unsigned integer.
row number contained in

the first response parcel
returned for this statement.
A value of zero corresponds
to parcels before those for
the actual first row's data
(Success, for example) while
a value one greater then the
number of rows corresponds
to parcels after those for the
actual last row's data
(EndRequest).
PBRTDB
264
2byte unsigned integer,

plus the number of
bytes specified by that
integer
Stored procedure database,

consisting of the length in
bytes of the name, followed
by that name in characters
from the current session
character set. The maximum
length of a name can be
obtained using the
DBCHQE SQL-limits query.

ResultSet Cursor
Table 22: ResultSet Parcel Field Information (continued)
TRDSPBRT
Flavor
Mnemonic
Field
Length
Value
PBRTPN
2byte unsigned integer,

plus the number of
bytes specified by that
integer
Stored procedure name,

consisting of the length in
bytes of the name, followed
by that name in characters
from the current session
character set. The maximum
length of a name can be
obtained using the
DBCHQE SQL-limits query
ResultSet Cursor
Sent to identify the last row fetched by an External Stored Procedure for a response being
propagated to the caller or application.
Parcel Data
Table 23 provides field information for the ResultSetCursor parcel.
Table 23: ResultSet Cursor Parcel Field Information
TRDSPBRK
Flavor
Mnemonic
175
TRDSPFRK
Field
Length
Value
PBRKSNUM
2byte unsigned integer
statement number
containing the last row
fetched by the procedure
PBRKNUM
row number of the last row

fetched by the procedure for
the statement
If the ResultSetCursor parcel is sent multiple times, the last one is honored.
Upon successful completion, an EndRequest parcel is returned. Upon unsuccessful
completion, either an Error or Failure parcel is returned. For Error, if the problem can be
corrected, the ResultSetCursor parcel can be resent; for Failure, the ResultSetCursor can not
be resent.
265

ResultSet Selection
ResultSet Selection
Sent to identify which statement responses to a request from an External Stored Procedure will
be propagated to the caller or application.
Parcel Data
Table 24 provides field information for the ResultSetSelection parcel.
Table 24: ResultSet Selection Parcel Field Information
TRDSPBRL
Flavor
Mnemonic
179
TRDSPFRL
Field
Length
Value
PBRLSLCT
2byte unsigned
integer
set to 0 if all statement

responses for the External
Stored Procedure are to be
propagated
set to 1 if only one statement
response is to be propagated
set to 2 if more than one
statement responses ares to
be propagated
zero or more
bytes
Optional selection cursors
If PBRLSLCT is set to 1, one selection cursor is required; set to 2, one or more selection cursors are
required; otherwise no selection cursors may be present.
Table 25: Selection Cursor Information
TRDSPALK
266
Field
Length
Value
PBRLLKSNM
statement number
containing the last row
fetched by the procedure
unused (must be zero)
PBRLKQNM
request number
PBRLKRNM
row number of the last row

fetched by the procedure for
the statement

Rewind
Upon successful completion, an EndRequest parcel is returned. Upon unsuccessful

completion, a Failure parcel is returned.
Rewind
Purpose
The Rewind parcel repositions spool file pointers to the beginning of the spool file.
Subsequent Resp or KeepResp parcels return data starting from the beginning of the spool file.
This operation can occur at any point when reading a response.
Parcel Data
Table 26 provides field information for the Rewind parcel.
Table 26: Rewind Parcel Field Information
Flavor Field
Parcel Body
Length
Parcel Body Fields
31
none
RowPosition
Purpose
Requests that the Teradata SQL response be repositioned to a specified row.
Usage Notes
RowPosition is included in a Continue to reposition to a particular row in the response.
If present, the RowPosition parcel must immediately proceed either the
ExtendedKeepRespond or KeepRespond parcel.
Parcel Data
Table 27 provides field information for the RowPosition parcel.
267

Run
Table 27: RowPosition Parcel Field Information
Parcel
Flavor
Parcel Body
Length
Parcel Body Fields
158
12
Statement Number : 2 bytes

Unused : 2 bytes
Offset : 8 bytes
Run
Purpose
Establishes a connection between an application and Teradata SQL.
Usage Notes
The Run parcel is sent after a logon has been completed or when the application requires a
different partition in the Teradata Database.
This parcel is generated by CLIv2 on behalf of the application.
The response to a Run parcel is a RunResponse parcel.
Parcel Data
Table 28 provides field information applies to the Run parcel.
Table 28: Run Parcel Field Information
Flavor
Parcel
Body
Length
Parcel Body Fields
38
16
PartitionName: 16 bytes
Field Notes
PartitionName is the name of the partition to which start requests are to be sent. If the
application submits a partition name with less than 16 bytes, CLIv2 right-pads it with blanks.
Valid PartitionName values include the following:
268
Partition
Name
Purpose
DBC/SQL
For sending Teradata SQL statements.
RBM
For communicating with the Resolver Base Module.

RunStartup
Partition
Name
Purpose
MONITOR
For communicating with the Performance Monitor.
Note: The RBM and MONITOR partitions are valid only for Teradata Database for UNIX
version 2 release 2 (or later), and for Teradata DBS for TOS version 1 release 5 (or later).
RunStartup
Purpose
The RunStartup parcel executes the users startup request and returns the results in Record
Mode. If a startup request is not stored with the data base, the response parcel is an Error
parcel with error code 3747.
Parcel Data
Table 29 provides field information for the RunStartup parcel.
Table 29: RunStartup Parcel Field Information
Flavor Field
Parcel Body
Length
Parcel Body Fields
none
SessionOptions
Purpose
The SessionOptions parcel sets various options for a session.
Parcel Data
Table 30 provides field information for the SessionOptions parcel.
269

SessionOptions
Table 30: SessionOptions Parcel Field Information
Flavor Field
Parcel Body
Length
114
10
Parcel Body Fields

Transaction
Semantics:
1 byte character
Mode:
1 byte character
Language
Conformance:
1 byte character
DateForm:
1 byte character
StatementStatus
1 byte character
CheckWorkload
1 byte character
Redrive
1 byte character
unused:
3 bytes
Field Notes
Semantics specifies the semantics to be used for requests within a transaction chosen as one of
the following:
Setting
Description
'D'
Default semantics
'T'
Teradata semantics
'A'
ANSI semantics
Mode specifies whether or not two-phase commit is used for transactions in the session,
chosen as one of the following:
Setting
Description
'2'
Two-phase commit (2PC) mode.
'N'
Non-2PC Mode.
Note: Two-phase commit is available only for Teradata Database for UNIX version 2 release 2
(or later), and for Teradata DBS for TOS version 1 release 5 (or later).
Conformance specifies whether or not SQL requests are to be checked for conformance with a
particular language definition chosen as one of the following:.
270

UserNameRequest
Setting
Description
'N'
No conformance.
'2'
ANSI entry-level (FIPS 127-2).
'3'
ANSI intermediate-level (FIPS 127-3).

Note: FIPS 127-3 conformance is not supported by the Teradata Database for
UNIX release 2.0.
StatementStatus specifies the type of statement status parcels to be returned by the Database,
chosen as one of the following:
Setting
Description
'O'
Success and OK parcels are returned.
'E'
ResultSummary parcels are returned.
CheckWorkload specifies whether the proprietary CHECK WORKLOAD statement will be

used, chosen as one of the following:
Setting
Description
'O'
The proprietary CHECK WORKLOAD statement will not be used.
'1'
The proprietary CHECK WORKLOAD statement will be used.
Redrive specifies whether or not a request for the session should be automatically redriven if
the Database restarts, chosen as one of the following:
Setting
Description
'N'
Requests interrupted by a Database restart must be aborted, not redriven.
'Y'
Requests interrupted by a Database restart may be redriven.
binary zeroes
Requests that the Database default for this action be used.
UserNameRequest
Purpose
The UserNameRequest parcel requests the return of the userid assigned to the session.
271

UserNameResponse
Usage Notes
When present, this parcel must be placed immediately after the Connect parcel.
Parcel Data
Table 31 provides field information for the UserNameRequest parcel.
Table 31: UserNameRequest Parcel Field Information
Flavor
Parcel Body
Length
Parcel Body Fields
136
0 or 1
When present ExtendedNameResponse: 1 byte
Field Notes
'ExtendedNameResponse' indicates whether the returned name may be longer than 30

bytes. The integer zero prohibits longer names; the integer one allows them.
UserNameResponse
Purpose
The UserNameResponse parcel returns the userid assigned to the session.
Usage Notes
This parcel can appear anywhere before the only End-request parcel.
Parcel Data
Table 32 provides field information for the UserNameResponse parcel.
Table 32: UserNameResponse Parcel Field Information
Flavor
Parcel Body
Length
137
Useridlength: 2
The Userid-length field is a two-byte unsigned integer

containing the number of bytes in the Userid field.
3-2304
Userid: 1 to 2304 bytes
Parcel Body Fields
Field Notes
272
The Userid field is a character string encoded in the character set of the associated request, varies in
length between 1 and 90 bytes, and contains the userid assigned to the session. The length is
contained in the Userid-length field.

VoteRequest
VoteRequest
Purpose
Requests a vote in a 2PC session.
Usage Notes
Two-phase commit is available only for Teradata Database for UNIX version 2 release 2 (or
later), and for Teradata DBS for TOS version 1 release 5 (or later).
The vote request parcel can be sent alone, or in a message (at the end of a sequence of request
and data parcels that define a Teradata SQL statement).
If the vote request is sent in the same message as a Teradata SQL statement, then the request
follows the rules for a multi-statement request; that is, all statements succeed, or all fail.
If your program is using the Initiate with Protocol-Function with the vote protocol function,
then the VoteRequest parcel is included after the request and data parcels.
The response is one of the following:
A Success parcel, indicating that the Teradata Database voted Yes, and that the transaction
is now in-doubt.
A Failure parcel, indicating either that the Teradata Database has voted No and rolled the
transaction back, or that the session is not in 2PC mode. The error code in Failure parcel
indicates why the Teradata Database did not commit the transaction
Parcel Data
Table 33 provides field information for the VoteRequest parcel.
Table 33: VoteRequest Parcel Field Information
Flavor
Parcel Body
Length
Parcel Body Fields
115
64
Coordinator (32 bytes)

RunUnitID (32 bytes)
Field Notes
The Coordinator field contains the text string name of the coordinator for the protocol.
The string consists of a two-byte length, followed by a 30-byte name.
The RunUnitID field contains a text string identifier of the run unit currently active for the
session.
The string consists of a two-byte length, followed by a 30-byte name.
273

VoteTerm
VoteTerm
Purpose
Requests a vote-and-terminate action in a 2PC session.
The VoteTerm parcel either can be sent alone or in a message (at the end of a sequence of
request and data parcels that define a Teradata SQL statement).
Usage Notes
Two-phase commit is available only for Teradata Database for UNIX version 2 release 2 (or
later), and for Teradata DBS for TOS version 1 release 5 (or later).
If the VoteTerm parcel is used with updates that change existing data, it will always result in a
commit.
If an immediate commit is not desired, use the VoteRequest parcel instead of the VoteTerm
parcel.
If the VoteTerm parcel is sent in the same message as a Teradata SQL statement, then the vote
and terminate request follows the rules for a multi-statement request (all statements succeed,
or all fail).
If your program is using the Initiate with Protocol-Function with the vote/terminate function,
then the VoteTerm parcel is included after the request and data parcels.
The response is one of the following:
A Success parcel indicating that the Teradata Database has committed the transaction
A Failure parcel indicating that the Teradata Database has rolled back the transaction or
that the session is not in 2PC mode.
The error code in the Failure parcel indicates why the Teradata Database could not commit
the transaction.
Parcel Data
Table 34 provides field information applies for the VoteTerm parcel.
Table 34: VoteTerm Parcel Field Information
274
Flavor
Parcel
BodyLength
Parcel Body Fields
116
none
APPENDIX D
How to Read the Syntax Diagrams
This appendix describes the rules that apply to the syntax diagrams used in this book.
Syntax Diagram Conventions

Notation Conventions
Item
Definition / Comments
Letter
An uppercase or lowercase alphabetic character ranging from A through Z.
Number
A digit ranging from 0 through 9.

Do not use commas when typing a number with more than 3 digits.
Word
Keywords and variables.

UPPERCASE LETTERS represent a keyword.
Syntax diagrams show all keywords in uppercase, unless operating system
restrictions require them to be in lowercase.
lowercase letters represent a keyword that you must type in lowercase, such as a
Linux command.
lowercase italic letters represent a variable such as a column or table name.
Substitute the variable with a proper value.
lowercase bold letters represent an excerpt from the diagram. The excerpt is
defined immediately following the diagram that contains it.
UNDERLINED LETTERS represent the default value.
This applies to both uppercase and lowercase words.
Spaces
Use one space between items such as keywords or variables.
Punctuation
Type all punctuation exactly as it appears in the diagram.
Paths
The main path along the syntax diagram begins at the left with a keyword, and proceeds, left
to right, to the vertical bar, which marks the end of the diagram. Paths that do not have an
arrow or a vertical bar only show portions of the syntax.
The only part of a path that reads from right to left is a loop.
275
Appendix D: How to Read the Syntax Diagrams

Continuation Links
Paths that are too long for one line use continuation links. Continuation links are circled
letters indicating the beginning and end of a link:
A
FE0CA002
When you see a circled letter in a syntax diagram, go to the corresponding circled letter and
continue reading.
Required Entries
Required entries appear on the main path:
SHOW
FE0CA003
If you can choose from more than one entry, the choices appear vertically, in a stack. The first
entry appears on the main path:
SHOW
CONTROLS
VERSIONS
FE0CA005
Optional Entries
You may choose to include or disregard optional entries. Optional entries appear below the
main path:
SHOW
CONTROLS
276
FE0CA004

If you can optionally choose from more than one entry, all the choices appear below the main
path:
READ
SHARE
JC01A010
ACCESS
Some commands and statements treat one of the optional choices as a default value. This
value is UNDERLINED. It is presumed to be selected if you type the command or statement
without specifying one of the options.
Strings
String literals appear in apostrophes:
'msgtext '
JC01A004
Abbreviations
If a keyword or a reserved word has a valid abbreviation, the unabbreviated form always
appears on the main path. The shortest valid abbreviation appears beneath.
SHOW
CONTROLS
CONTROL
FE0CA042
In the above syntax, the following formats are valid:
SHOW CONTROLS
SHOW CONTROL
Loops
A loop is an entry or a group of entries that you can repeat one or more times. Syntax
diagrams show loops as a return path above the main path, over the item or items that you can
repeat:
,
,
(
cname
3
4
)
JC01B012
277

Read loops from right to left.

The following conventions apply to loops:
IF...
THEN...
there is a maximum number of

entries allowed
the number appears in a circle on the return path.
there is a minimum number of

entries required
the number appears in a square on the return path.
a separator character is required

between entries
the character appears on the return path.
In the example, you may type cname a maximum of 4 times.
In the example, you must type at least three groups of column

names.
If the diagram does not show a separator character, use one

blank space.
In the example, the separator character is a comma.
a delimiter character is required

around entries
the beginning and end characters appear outside the return

path.
Generally, a space is not needed between delimiter characters
and entries.
In the example, the delimiter characters are the left and right
parentheses.
Excerpts
Sometimes a piece of a syntax phrase is too large to fit into the diagram. Such a phrase is
indicated by a break in the path, marked by (|) terminators on each side of the break. The
name for the excerpted piece appears between the terminators in boldface type.
The boldface excerpt name and the excerpted phrase appears immediately after the main
diagram. The excerpted phrase starts and ends with a plain horizontal line:
LOCKING
excerpt
A
HAVING
con
excerpt
where_cond
,
cname
,
col_pos
JC01A014
278

Multiple Legitimate Phrases

In a syntax diagram, it is possible for any number of phrases to be legitimate:
dbname
DATABASE
tname
TABLE
vname
VIEW
JC01A016
In this example, any of the following phrases are legitimate:
dbname
DATABASE dbname
tname
TABLE tname
vname
VIEW vname
Sample Syntax Diagram

,
CREATE VIEW
viewname
AS
A
LOCKING
cname
CV
LOCK
ACCESS
dbname
A
DATABASE
tname
FOR
SHARE
IN
READ
TABLE
WRITE
EXCLUSIVE
vname
VIEW
EXCL
,
SEL
B
MODE
expr
,
FROM
qual_cond
tname
.aname
C
HAVING cond
;
qual_cond
,
WHERE cond
GROUP BY
cname
,
col_pos
JC01A018
279

Diagram Identifier
The alphanumeric string that appears in the lower right corner of every diagram is an internal
identifier used to catalog the diagram. The text never refers to this string.
280
Index
Numerics
2PC
disabling IRF 99
enabling internal sessions 156
in-doubt sessions
committing 96
displaying 131
rollback 196
internal TDP sessions 71
manual in-doubt resolution 99
A
ADD CELLS command 87
ADD XMSCELLS command 87
ATTACH CP command 89
ATTACH IFP command 91
Attributes
display server attributes 140
Authority
granting to issue TDP commands 93
levels of command issuing 77
TDP capabilities 77
where to issue 94
AUTHORIZ command 93
AUTHORIZ command, TDP 77
C
Causes 111
Cells, initial numbers 120
Channel block
display number of 118
Channel Processor 22
Channel sharing 42
Character set 198
display default 140
list supported sets 140
checksum
SET CHECKSUM command 200
Client software
tuning options 37
COMMIT command 96
Communication character
setting for TDP 201
Connect parcel 258
CP
attaching to TDP 210

displaying status 123
shutdown record 43
starting 210
stopping 223
D
Database external authentication (see Logon, authenticated
by TDP) 53
DBCCMD
invoking from a program 74
return codes 74
using 73
DDNAME 233
default interface
EXCPVR 26
DETACH CP command 97
DETACH IFP command 98
Diagnostics
writing to console, start 170
writing to console, stop 112
DISABLE IRF command 99
DISABLE LGUX command 100
DISABLE LOGONS command 101
DISABLE POOL command 102
DISABLE SECLOGON command 105
DISABLE SESSION RESERVE command 107
DISABLE SMF command 109
DISABLE TDPSTATS command 111
DISABLE TEST command 112
DISABLE TIME command 113
DISABLE TMON command 114
DISABLE TRAP command 115
DISABLE UAX command 116
DISABLE USEC command 117
DISPLAY CCU command 118
DISPLAY CELLS command 119
DISPLAY CHECKSUM command, TDP 122
DISPLAY CP command 123
DISPLAY IFP command 129
DISPLAY INDOUBT command 131
DISPLAY JOB command 133
DISPLAY LIMIT 135
DISPLAY MODULE command 136
DISPLAY POOL command 137
DISPLAY QUEUES command 139
281
Index
DISPLAY SERVER command 140

DISPLAY SESSIONS command 142
DISPLAY SMF command 147
DISPLAY SP command 148
DISPLAY STORAGE command 151
DISPLAY TDP command 152
DISPLAY TDPSTATS command 155
E
ENABLE IRF command 156
ENABLE LGUX command 158
ENABLE LOGONS command 159
ENABLE POOL command
Operator commands
ENABLE POOL 160
ENABLE SECLOGON command 163
ENABLE SESSION RESERVE command 165
ENABLE SMF command 167
ENABLE TDPSTATS command 168
ENABLE TEST command 170
ENABLE TIME command 171
ENABLE TMON command 172
ENABLE TRAP command 173
ENABLE UAX command 175
ENABLE USEC command 176
External Security Manager Interface (security logon
function) 61
F
Features
list server features 140
H
HSI time stamps 37
HSIOSSI, associating with TDP 187
HSISPB
tuning options 46
I
I/O
choosing mode 182
increasing buffers 181
mode options 46
IBM, LPAR 20
ID
display logical host 140
IFP
allocating to TDP 89, 91
attaching to TDP 212
deallocating from TDP 97, 98
282
starting 197, 212

stopping 224
Implicit logon (see Logon, authenticated by TDP) 53
INITIAL commands
INITIAL CCU 177
INITIAL DLYTIME 178
INITIAL IACMODE 179
INITIAL IOBUFS 181
INITIAL IOMODE 182
INITIAL JOBWAIT 184
INITIAL LSQA 185
INITIAL MSGPREF 186
INITIAL OSSISUFX 187
INITIAL PCSUFX 188
INITIAL TRUNCRSP 189
INITIAL TRUNCRSP command 189
Initiate With Protocol-Function
using with VoteTerm parcel 274
IOSDRIVR, using 182
IRF
enabling 156
internal TDP sessions 71
IVRunStartup parcel 260
J
Job
changing wait time 184
L
LGUX exit (see TDPLGUX) 52
Logical Host 20, 22
LOGOFF command 190
Logoff parcel 260
LOGOFF POOL command 192
Logoff record 44
Logon
authenticated by TDP 52, 53
disabling 101
disabling to pools 102
enabling 159
enabling to pools 160
expired password 50
violations information 117
with null password 50, 216
LSQA, controlling in address space 185
M
Memory
adding cells to main 87
displaying cell information 119
Memory cell
Index
optimization 42
usage analysis example 41
MODIFY POOL command 193
MODIFY SECLOGON command 194
multiple databases
two-phase commit 24
Updating 23
multiple TDP releases 20
multiple TDPs 20
Multi-TSR
parcel described 262
O
Operator commands
ADD CELLS 87
ADD XMSCELLS 87
ATTACH CP 89
AUTHORIZ 93
COMMIT 96
DETACH CP 97
DETACH IFP 98
DISABLE IRF 99
DISABLE LGUX 100
DISABLE LOGONS 101
DISABLE POOL 102
DISABLE SECLOGON 105
DISABLE SESSION RESERVE 107
DISABLE SMF 109
DISABLE TDTSTATS command 111
DISABLE TEST command 112
DISABLE TIME command 113
DISABLE TMON 114
DISABLE TRAP 115
DISABLE UAX 116
DISABLE USEC 117
DISPLAY CCU 118
DISPLAY CELLS 119
DISPLAY CP 123
DISPLAY IFP 129
DISPLAY INDOUBT 131
DISPLAY JOB 133
DISPLAY MODULE 136
DISPLAY POOL 137
DISPLAY QUEUES 139
DISPLAY SERVER 140
DISPLAY SESSIONS 142
DISPLAY SMF 147
DISPLAY SP 148
DISPLAY STORAGE 151
DISPLAY TDP 152
DISPLAY TDPSTATS 155
ENABLE IRF 156
ENABLE LGUX 158
ENABLE LOGONS 159

ENABLE SECLOGON 163
ENABLE SESSION RESERVE 165
ENABLE SMF 167
ENABLE TDPSTATS 168
ENABLE TEST 170
ENABLE TIME 171
ENABLE TMON 172
ENABLE TRAP 173
ENABLE UAX 175
ENABLE USEC 176
granting authority to issue 93
issuing from CLIv2 applications 75
issuing from MVS 72
issuing from VOS3 72
LOGOFF 190
LOGOFF POOL 192
MODIFY POOL 193
MODIFY SECLOGON 194
ROLLBACK 196
RUN 27, 197
SET CHARSET 198
SET COMCHAR 201
SET MAXSESS 203
SET STORAGE 204
SET USERID 206
SHUTDOWN 208
START CP 26, 210
START IFP 212
START POOL 214
STOP CP 223
STOP IFP 224
STOP POOL 225
where to issue 72, 81
Operator commands,
ATTACH IFP 91
P
Parallelism factor
display 140
Parcel
Connect 258
IVRunStartup 260
Logoff 260
Request 250
ResultSet Selection 266
Rewind 267
RunStartup 269
structure 247
type 250
Performance
CP shutdown record 43
general tuning options 37
283
Index
logoff record 44
measurement
SMF records 42
SMS records 42
VOS3 42
z/OS 42
statistics 38
system options 42
TDP cells 38
tuning MVS with I/O options 46
Performance Monitor
partition
sending requests to 269
Pools
definition 78
disabling logons 102
displaying information 137
enabling 214
enabling logons 160
ending 192
logging off 79
logging on 78
multiple simultaneous 78
sessions, changing number 193
stopping 225
with null password 216
product version numbers 3
Program call cells
adding 87
displaying usage 119
Q
Queue, displaying status of internal 139, 140
R
Request parcel, overview 250
Resolver Base Module
partition
sending requests to 268
ResultSet Selection parcel 266
Rewind parcel 267
ROLLBACK command 196
RUN command 27, 197
RunStartup parcel 269
S
Security
monitoring violations 117
security logon function 61
TDPLGUX 52
Security logon function 61
bypassing 63
284
disabling 63, 105

enabling 63, 163
modifying 194
operation 62
setup procedure 64
using with session pools 63
using with TDPLGUX 62
validated logon function 64
Security Manager Interface (security logon function) 61
Security violations record 44
Segment
maximum number 140
maximum size 140
Semantics
display 140
SequenceNumber
Multi-TSR field 263
Server
display attributes 140
Session pools
changing number in 193
definition 78
enabling 214
logging off 79
logging on 78
logoff 192
multiple simultaneous 78
stopping 225
with null password 216
Session Processor 22
Sessions
disabling internal for 2PC 99
enabling internal 156
forcing off 190
in-doubt
committing 96
displaying 131
rollback 196
logoff record 44
reserve capacity for failure 165
reserved capacity, releasing 107
setting maximum number 203
SET CHARSET command 198
SET CHECKSUM command, TDP 200
SET COMCHAR command 201
SET LIMIT 202
SET MAXSESS command 203
SET STORAGE command 204
SET USERID command 206
setting for TDP 198
SHUTDOWN command 208
SMF recording
Index
disabling 109
enabling 167
shutdown record 38
SMS recording
disabling 109
enabling 167
shutdown record 38
software releases
supported 3
SP, displaying status 148
specifying
TDP version 26
SQL
GRANT LOGON 50
START CP command 26, 210
START IFP command 212
START POOL command 214
Statistics
logoff record 44
security violations record 44
TDP shutdown record 45
Status
Multi-TSR parcel field 263
STOP CP command 223
STOP IFP command 224
STOP POOL command 225
Structure-protocol Termination Record 45
T
TDP
authorization capabilities 77
channel error logging 227
command response types 75
communication character, setting 201
communication mode, changing 179
CP
attaching 210
CPs assigned to 123
HSIOSSI association 187
IFP
allocating 89, 91
attaching 212
deallocating 97, 98
initializing 70
initializing from TDPPARM 70
internal queues, displaying 139, 140
logon
disabling 101
enabling 159
memory management 37
memory statistics, displaying 38
message prefix, suppressing 186
operation 69
performance
logoff record 44
SMF records 43
SMS records 43
statistics 38
tuning options 37
session capacity
release reserved 107
reserve for failure 165
sessions, setting maximum number 203
setting character set 198
shutdown 76
shutdown record 45
SMS 38
SMF shutdown record 38
SP status, displaying 148
status, displaying 152
stopping 208
TDPLGUX
disabling 100
enabling 158
TDPNSPCI association 188
TDPUAX
enabling requests to 175
stopping requests to 116
TDPUSEC
enabling communication to 176
stopping communication with 117
TDPUTCE
disabling calls to 114
enabling calls to 172
throughput, improving 87
user validation 77
userid
setting for internal sessions 206
VOS3
canceling 76
security features 49
starting under 69
tuning with HSISPB 46
z/OS
canceling 76
security features 49
starting under 69
tuning with HSISPB 46
tuning with I/O mode options 46
TDP cell
optimization 39
performance 42
285
Index
system options 42
usage optimization 42
TDP Operator Message Character Set 76
TDP User Address Space Exit. See TDPUAX
TDP User Logon Exit Interface. See TDPLGUX
TDP User Security Interface. See TDPUSEC
TDP0113 71
TDPINT 99
TDPLGUX
customizing 54
disabling 100
enabling 158
installing customized 55
logon violations record 45
operation 52
security functions 52
security violations record 44
using with security logon 62
TDPLGUX exit
activating 52
deactivating 52
new versions 52
TDPNSPCI, TDP association 188
TDPPARM
creating your own 71
message routing 71
using to initialize TDP 70
TDPPARM, comments 71
TDPPARM, editing 71
TDPPARM, record format 71
TDPPARM, record length 71
TDPPARM, sequence numbers 71
TDPUAX
customizing 50
disabling 116
enabling 175
operation 49
TDPUAX exit
activating 49
deactivating 49
new versions 49
TDPUSEC
customizing 60
disabling 117
enabling 176
operation 59
TDPUTCE
collection applications 57
customizing 57
definition 55
286
disabling 114
enabling 172
VOS3, installing customized 58
z/OS, installing customized 58
TDPUTCE exit 55
deactivating 55
new versions 55
Teradata Server
pools, logging on 78
179
TEST mode
disabling 112
enabling 112, 170
Time
disabling 113
enabling 171
TMON exit (see TDUPCE) 55
Tuning options
HSISPB parameters 46
system 42
TDP 37
U
UAX exit (see TDPUAX) 49
undocumented interface
z/OS IOSDRIVR 26
Userid
setting for internal TDP sessions 206
V
Validated logon function
using security logon with 64
version numbers 3

Teradata Director Program: Reference

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Teradata Director Program: Reference

Uploaded by

Copyright:

Available Formats

Teradata Director Program

System and application programmers

Database administrators and relational database developers

Teradata Database 14.0

Teradata Tools and Utilities 14.00

Teradata Director Program Version 14.00

To locate detailed supported-release information:

Under Online Publications, click General Search.

Type 3119 in the Publication Product ID box.

Under Sort By, select Date.

Teradata Director Program Reference

Changes to This Book

Updated Teradata Director Program Reference to reflect Teradata products

Teradata Director Program Reference

Use the Release Definition for the following

Overview of all of the products in the

3 Type 2029 in the Publication Product ID box.

Operating systems and Teradata

Use the Teradata Information Products web

2 Under Online Publications, click General Search.

the search results.

Browse by Category, click Data Warehousing.

For a list of Teradata Tools and Utilities

Access a link to a downloadable CD-ROM

Browse by Category, click Data Warehousing.

Use the Teradata Information Products web

Teradata Director Program Reference

The Teradata home page provides links to

Executive reports, case studies of

Teradata Director Program Reference

Teradata Director Program Reference

Teradata Director Program Reference

Types of TDP Command Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Teradata Director Program Reference

DISPLAY INDOUBT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131

Teradata Director Program Reference

Teradata Director Program Reference

Teradata Director Program Reference

Teradata Director Program Reference

Teradata Director Program Reference

Figure 1: Typical Teradata System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Teradata Director Program Reference

Teradata Director Program Reference

Table 1: Function Codes Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Teradata Director Program Reference

Table 33: VoteRequest Parcel Field Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273

Teradata Director Program Reference

TDPs Role in a Teradata System

Logical Hosts, Channel Processors, and Session Processors

Call-Level Interface (CLI) in a Teradata System

Teradata Session Requests

Externally Coordinated Commit

TDPs Role in a Teradata System

Teradata Director Program Reference

TDP provides a high-performance communication interface between mainframe applications

Teradata Director Program Reference

No application resources except storage explicitly designated by the application is

No changes are made to the application's environment. No authorization is extended

Logical Hosts, Channel Processors, and Session

Teradata Director Program Reference

Call-Level Interface (CLI) in a Teradata System

Teradata Director Program Reference

Teradata Session Requests