Customizing the TDPUSEC - Teradata Director Program

Teradata® Director Program Reference

Product
Teradata Director Program
Release Number
17.00
Published
June 2020
Language
English (United States)
Last Update
2020-06-18
dita:mapPath
pxm1544831938750.ditamap
dita:ditavalPath
obe1474387269547.ditaval
dita:id
B035-2416
lifecycle
previous
Product Category
Teradata Tools and Utilities

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 the TDPSNAP 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 might record the dump if the standard resources are available (a SYSUDUMP DD statement on z/OS, for example). It is the exit’s responsibility to properly manage its subtasks so that such failures do not impact its operation.

  • 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:

    • Do nothing but return an error code to the caller.
    • In z/OS or VOS3, issue a WTO to the security console.
    • (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.