16.20 - Protected Mode Process and Server Administration for C/C++ External Routines - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - SQL External Routine Programming

Advanced SQL Engine
Teradata Database
Release Number
Release Date
April 2020
Content Type
Programming Reference
Publication ID
English (United States)

Executing C or C++ external routines in protected mode requires additional administration.

The database installation process creates a local, operating system-native user with the name 'tdatuser' on each node the database runs on. The 'tdatuser' ID is associated with two default processes per AMP vproc and PE vproc for running external routines in protected mode.

Follow these rules to guarantee that your external routines and Teradata Database function properly:
  • Do not delete 'tdatuser'.
  • Do not add a password for 'tdatuser'.

    This prevents logon to the user on the system.

  • If you think you need to make changes, please contact the Teradata Support Center first.

In addition to creating 'tdatuser', the installation process also creates a new group on each node called 'tdatudf'. The preceding admonishments apply to the 'tdatudf' group: do not change it.

The 'tdatuser' user has no special privileges on the system. No one should be able to log on as 'tdatuser'.

If an external routine that runs in protected mode needs to access system resources, to open a file for example, you must set the appropriate access privileges to include 'tdatuser'.

By default, each vproc has only two protected mode servers that are shared among all transactions executing protected mode external routines. To increase the number of protected mode servers per vproc, use the cufconfig utility. For more information, see Teradata Vantage™ - Database Utilities , B035-1102 .

A table function that executes in protected mode reserves a server process for the duration of the step that executes the table function. It is important that the number of protected mode servers that you allocate is greater than the number of simultaneous queries from different sessions that you plan to run. If you allocate too few, then some will have to wait. If all the servers are used up, an undetected deadlock could also occur.