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

SQL External Routine Programming

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Published
July 2021
Language
English (United States)
Last Update
2021-07-27
dita:mapPath
rin1593638965306.ditamap
dita:ditavalPath
rin1593638965306.ditaval
dita:id
B035-1147
lifecycle
previous
Product Category
Teradata Vantageā„¢

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 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.