Customizing TDPUAX - Teradata Director Program

Teradata® Director Program Reference - 17.20

Teradata Director Program
Release Number
June 2022
English (United States)
Last Update
Product Category
Teradata Tools and Utilities
When customizing a TDPUAX module, the following points must be considered:
  • 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.
  • TDPUAX must specify AMODE 31 because the data buffers might 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 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 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 caller’s 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
  • Requestor information
  • Parameter information
  • Logon information
    The TDP identifier and separating slash that CLIv2 allows as a prefix to the Logon String, and the ending semicolon character, are removed by CLIv2, 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, X’0E’, and followed by the Shift-in control character, X’0F’. 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:

Return Code Meaning
0 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.