Rules and Restrictions for Using Routines
The following sections describe the operational rules and restrictions for using INMOD and notify exit routines in Teradata TPump jobs.
INMOD and notify exit routine names must be unique within the system.
A Teradata TPump job can specify one INMOD routine with each IMPORT command. These specifications can be to the same or different INMOD routines.
In addition to the multiple INMOD routines, each Teradata TPump job can specify an exit routine with the NOTIFY... EXIT option of the BEGIN LOAD command.
Compiling and Linking Routines
The methods for compiling and linking routines vary with the operating system. The following sections describe the methods for z/OS, UNIX OS, and Windows.
On mainframe‑attached z/OS client systems, INMOD and notify exit routines must be compiled under IBM C.
Using UNIX Operating System
On network‑attached client systems for the UNIX OS, INMOD and notify exit routines must:
On network‑attached Windows client systems, INMOD and notify exit routines must:
For more information, see Appendix C: “INMOD and Notify Exit Routine Examples” for sample programs and procedures that compile and link INMOD and notify exit routines for the operating system environment.
Addressing Mode on z/OS Systems
Either 31‑bit or 24‑bit addressing for INMOD routines can be used on mainframe‑attached systems. The 31‑bit mode provides access to more memory, which enhances performance for Teradata TPump jobs with a large number of sessions.
Use the following linkage parameters to specify the addressing mode when building INMOD routines for z/OS systems:
INMOD Routine Compatibility with Other Load Utilities
FDL‑compatible INMOD routines that were created for FastLoad by including the FDLINMOD parameter as the USING (parms) option of the IMPORT command can be used. Using this parameter provides compatible support operations except for the way checkpointing is performed:
If Teradata Database experiences a restart/recovery operation, Teradata TPump starts over and gets the records again from the beginning of the range.
Under these same circumstances, if a BEGIN LOAD command included a CHECKPOINT rate other than zero, Teradata TPump terminates with an error condition.
If Teradata Database experiences a restart/recovery operation and the INMOD routine supports recovery, Teradata TPump continues the data acquisition activity from the last recorded checkpoint.
Note, however, that the source sequence numbers generated by Teradata TPump may not correctly identify the sequence in which the INMOD routine supplied the records. The data is still applied correctly, however, despite this discrepancy.
An FDL‑compatible INMOD routine cannot be specified with the INFILE specification of a Teradata TPump IMPORT command.
When an INMOD routine is specified with the INFILE specification:
The combination of an FDL‑compatible INMOD routine with a Teradata TPump INFILE specification is not valid because an FDL‑compatible INMOD routine must always perform the file read operation.
To support Teradata TPump restart operations, the INMOD routine must support checkpoint operations, as described in “The Teradata TPump/INMOD Routine Interface” on page 217.
If an INMOD routine that does not support the checkpoint function is used, the job may encounter problems when Teradata TPump takes a checkpoint.
By default, Teradata TPump takes a checkpoint every 15 minutes. The Teradata TPump checkpoint function can be bypassed by specifying a CHECKPOINT rate of zero in the BEGIN LOAD command; that way, the job completes without taking a checkpoint.
Though this would nullify the Teradata TPump restart/reload capability, it would allow an INMOD routine that does not support the checkpoint function to be used.