Specifying an Access Module| Teradata Parallel Transporter User Guide - Specifying an Access Module - Parallel Transporter

Teradata® Parallel Transporter User Guide - 17.20
Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
Lake
VMware
Product
Parallel Transporter
Release Number
17.20
Published
June 2022
ft:locale
en-US
ft:lastEdition
2023-08-25
dita:mapPath
uzp1645128359760.ditamap
dita:ditavalPath
tvt1507315030722.ditaval
dita:id
B035-2445
lifecycle
previous
Product Category
Teradata Tools and Utilities
Use the following attributes in the DataConnector operator definition to specify the optional use of an access module:
  • AccessModuleName

    Each access module has a pre-assigned name depending on the operating system on which it is installed. For instance, the JMS access module running on Solaris is named libjmsam.so.

  • AccessModuleInitStr

    Specifies the access module initialization string.

For detailed information about configuring and using access modules with Teradata PT, see Teradata® Tools and Utilities Access Module Reference, B035-2425.

For information about creating custom access modules, see Teradata® Parallel Transporter Operator Programmer Guide, B035-2435.

z/OS Considerations

When using access modules residing within a z/OS program library, either a PDS or a PDSE, the access module name provided to the producer operator using the AccessModuleName attribute is the member name within the library. It may be a system library, private library, or even a temporary library.

If a system library contains the access module, no further JCL is required. However, when a private or temporary library houses the access module, a JOBLIB DD statement or a STEPLIB DD statement is required within the jobstream to designate the library containing the access module.

The following example shows a typical JOBLIB DD statement for a private library in a Teradata PT jobstream:

//JOBLIB DD DISP=SHR,DSNAME=STV.TJ50APP.TWB.L
// DD DISP=SHR,DSNAME=STV.TJ50APP.APP.L
// DD DISP=SHR,DSNAME=PROD.TERADATA.LOAD
where:
  • STV.TJ50APP.TWB.L is the Teradata PT installation library for the TDP variant.
  • STV.TJ50APP.APP.L is the CLI installation library for the TDP variant.
  • PROD.TERADATA.LOAD is a private library that contains all Teradata-related access modules.
//JOBLIB DD DISP=SHR,DSNAME=STV.TJ50APP.TWB.GTW.L
// DD DISP=SHR,DSNAME=STV.TJ50APP.APP.GTW.L
// DD DISP=SHR,DSNAME=PROD.TERADATA.LOAD

This is the recommended concatenation order for these libraries.

These dataset names are just examples. Actual dataset names will be different after installation.

When using access modules residing within a z/OS program library, either a PDS or a PDSE, the access module name provided to the producer operator using the AccessModuleName attribute is the member name within the library. It may be a system library, private library, or even a temporary library.

If a system library contains the access module, no further JCL is required. However when a private or temporary library houses the access module, a JOBLIB DD statement or a STEPLIB DD statement is required within the job stream to designate the library containing the access module. The following example shows a typical JOBLIB DD statement for a private library in a Teradata PT job stream:

//JOBLIB  DD  DISP=SHR,DSNAME=STV.TI70APP.TWB.LOAD
//        DD  DISP=SHR,DSNAME=STV.TI70APP.APP.L
//        DD  DISP=SHR,DSNAME=PROD.TERADATA.LOAD
where:
  • STV.TI70APP.TWB.LOAD is the Teradata PT installation library.
  • STV.TI70APP.APP.L is the CLI installation library.
  • PROD.TERADATA.LOAD is a private library that contains all Teradata-related access modules.

This is the recommended concatenation order for these libraries.