Archives of the TeradataForum

Message Posted: Thu, 27 Jul 2006 @ 16:04:51 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

As I am sure you've discovered, some shell environments have limits on the maximum return code value that can be set so trying to set the exit from BTEQ equal to whatever errorcode value has been detected/trapped can be a problem. My usual attack plan for this type of thing is to check/differentiate in the BTEQ script the specific error condition and set a unique return code value upon exit from BTEQ that can be accepted by the shell environment. Then, your shell script can be coded to follow unique recovery steps as necessary depending on the specific return condition detected. For example:

     INSERT INTO dss_tables.dly_sales_TEMP
     SELECT * FROM dss_tables.dly_sales_tbl ;

     .IF ERRORCODE=2828 THEN .GOTO ERRUNQ            ** if error code = 2828
     then set 77 return code for shell to detect

     .QUIT

     .LABEL ERRUNQ

     .QUIT 77

In this case the BTEQ script would set a return code of 77 if the insert completes with a 2828 and you can key off that in your shell script to execute a suitable set of recovery steps or follow a unique processing flow for that condition if desired.

As for your question about if BTEQ would had encounter a different errorcode value if the resubmit had subsequently failed my understanding is Yes. I have not experienced that but I strongly suspect that would be the case. If someone has a definitive answer, I too would be interested in that info.....

Cornelius Meade III
EDS - Consulting Services/BI/CRM

	<Prev	Next>		<<First	<Prev	Next>	Last>>