Teradata Database generates one or more parcels in response to a request it receives. It then sends the Teradata SQL response in portions containing whole parcels. The number of parcels in the portion is the maximum number that can fit in the buffer for that request.
Response parcels are screened by CLIv2 before the application receives them. If a problem develops and CLIv2 is able to resolve it, the application may not see an error returned by the Teradata Database. For example, if CLIv2 screens an Error parcel which indicates that the response buffer is too small, CLIv2 will automatically expand the buffer and request that portion of the buffer again. The application will not know that the error existed and that it was resolved by CLIv2.
The application can process the response parcels by calling DBCHCL repeatedly with the fetch function. As each parcel is encountered, the application must check whether it is an error or failure parcel, even when the return code from the fetch is zero. A zero return code only indicates that CLIv2 and TDP have encountered no problems. To learn whether the Teradata Database has detected problems, the parcel flavor must be checked.