CON (Connect) logs on to Teradata Database and arranges to have the specified services available for all requests on that session.
Connect also allocates internal control structures that CLIv2 uses to store session context.
- If no Logon String is supplied or logon mechanism, a TDP logon exit must furnish the necessary information to complete the logon request. If a TDP logon exit does not exist or is disabled, the connect will be rejected by TDP.
- The application should call the ERQ function after processing the CON function, regardless of the success or failure of the connect. This releases internal resources used during connect processing.
- DSC must be performed for each CON request. If the CON results in a nonzero return code, DSC should be called immediately. Otherwise, DSC should be called when the application has completed all work for the session.
- If Return Code is 0, the application must invoke the FET function to obtain the final status of the connect call.
- If Connect-type was R, the FET call results in a Return Code of 33 if the connect was successful.
- If Connect-type was C, the parcels must be processed to determine success or failure of the connect.
- The FET returns three additional DBCAREA fields set only when CON is being processed. These fields are:
- Additional fields will be set as normal by the FET call.
For a discussion of the call and the fields used, see DBCHCL FET Function.
DBCAREA Input Fields
Before using the Connect function, the application must set the DBCAREA fields in the first table and may optionally set those in the second table depending on the application's requirements.
|DBCAREA Input Fields Optional for the Connect Function|
DBCAREA Output Fields
Upon completion of the Connect function, CLIv2 will always set DBCAREA fields in the first table and will set those in the second table if the function was successful.
|DBCAREA Output Fields Always Set for the Connect Functions|
|DBCAREA Output Fields Set by Successful Connect Functions|