Comparisons between PM/API and Teradata SQL Requests | VantageCloud Lake - Comparisons between PM/API and Teradata SQL Requests - Teradata VantageCloud Lake

Lake - Monitor Resources and Performance
Deployment
VantageCloud
Edition
Lake
Product
Teradata VantageCloud Lake
Release Number
Published
February 2025
ft:locale
en-US
ft:lastEdition
2025-11-21
dita:mapPath
wyu1683671641248.ditamap
dita:ditavalPath
pny1626732985837.ditaval
dita:id
wyu1683671641248

There are both similarities and differences between PM/API applications and Teradata SQL applications, such as Basic Teradata Query (BTEQ), special utilities (for example, Teradata FastLoad), and third-party software.

Similarities

The similarities between a PM/API based application and a Teradata SQL-based application include:
  • Data types supported for input and output data in PM/API applications are a subset of those data types supported by Teradata SQL.
  • Fixed length character data is blank padded on the right.
  • NULL returned for the PclRecordType response parcel is equal to NULL returned by Teradata SQL (see Response Groups).

Differences

The differences between a PM/API based application and a Teradata SQL-based application are:
  • A PM/API application issues requests through a session partition named MONITOR.
  • The MONITOR partition returns an error message if you use any of the following Teradata SQL partition capabilities:
    • Keep Response processing mode
    • Run a rewind operation
    • Run the start-up operation
    • Field mode request
    • CleanUp request
    • P (Prepare) or S (Setup) request processing option of the DBCAREA
  • Keywords used by the MONITOR PM/API requests are different from keywords in Teradata SQL. However, both have the same rules for identifiers.
  • MONITOR query processing, unlike Teradata SQL, produces dynamic data.
  • Data String, which defines the input data, is required in a PM/API application when using CLIv2, but optional in Teradata SQL.

Keywords/Reserved Words

The following keywords are database-reserved words:
  • ABORTSESSION
  • MONITOR
  • MONRESOURCE
  • MONSESSION
  • SETRESRATE
  • SETSESSRATE
The following keywords are database non-reserved words that are permitted as object names, but discouraged because of the possible confusion that may result:
  • MONSQL
  • MONVERSION

For a complete list of words that are unavailable for use as object names, see Restricted Words.

Using Teradata SQL GRANT and REVOKE Statements

If you are using a Teradata SQL-based application, you can issue the GRANT (SQL Form) and REVOKE (SQL Form) statements.

A change in privileges can temporarily block the request of an active MONITOR session, because the system must look up the new privileges before accepting more requests from the affected user. If the system query is blocked by a lock on a database dictionary table, or if there is another system processing bottleneck, you cannot issue MONITOR requests until you acquire the new set of privileges. However, MONITOR requests submitted from the system console are not blocked by a change in privileges, because no privileges are necessary to issue MONITOR requests on the system console.

Using ABORT SESSION Request

If you are using a PM/API based application, you can issue the CLIv2 or the Teradata JDBC Driver ABORT SESSION request.

With the proper privileges granted, you can stop and log off a database user.

ABORT SESSION Error Message
Targets a current database request or session Transaction is aborted.
Targets a request or session after the user has logged off from the database Session is not logged on.

The error message is not returned to the user of the affected session until ABORT SESSION completes rolling back the current transaction or, if applicable, the session is logged off.

The status of an active session determines when the user gets the error message.

Condition When You Issue ABORT REQUEST Error Message
A request is outstanding for the user session. Sent as a response to the current request.
No request is outstanding, but a session is in progress. Sent to user when the system gets the next request.

For more information on this request, see ABORT SESSION.