- Supplies the session id, if the DBCAREA has been used for any other session since last used for this session
- Supplies the length of and a pointer to the input data, if the STARTUP string contains a Teradata SQL statement with a USING modifier
- Changes the setting of the processing options
- Supplies the length of and a pointer to the Move area, if the Move Mode processing option was chosen
- Supplies the function code to the Run Startup Request (DBFRSUP)
The application then calls DBCHCL.
DBCHCL prepares either a RunStartup, IVRunStartup or FMRunStartup parcel in the message body of the Request Buffer depending on the value of the Record Mode options flag, and then prepares a Resp or KeepResp parcel depending on the value of the Keep Mode flag, and a Data or Indic data parcel if the Teradata SQL request contained a Teradata SQL statement with a USING modifier in the Request Buffer.
In the MTDP Control Block, DBCHCL provides a pointer to the Request Buffer and the length including the LAN header structure, of the data in the buffer, provides the length of and a pointer to the Response Buffer, sets the selfrecov option (if needed), and sets the function code to MTDPSTA. DBCHCL then calls MTDP.
MTDP prepares and sends a Start Request message to the database. It then returns control to DBCHCL.
If the return code in the MTDP Control Block is normal and the wait data option for the run startup request is set to Y, DBCHCL sets the wait data option in the MTDP control block to TRUE, sets the function code to MTDPRET, and calls MTDP.
MTDP checks to see if the Start Response message has been received from the database. With the wait data option set to “on,” MTDP will wait for the arrival of the Start Response message and then return control to DBCHCL.
Based on the return code in the MTDP Control Block, DBCHCL generates an error or success message string in the message field of the DBCAREA and DBCHCL returns control to the application program.
If the return code in the DBCAREA is not normal, the application program makes the appropriate changes and re-submits the DBCAREA to DBCHCL, as above. Otherwise, the application program saves the request id if the application program plans to use the DBCAREA for any other request concurrently. The application consumes the Teradata SQL response as it would any other, see below. The interface is then ready to process regular Teradata SQL requests.