Date:         Fri, 31 May 1996 08:49:27 GMT
Reply-To:     Don Stanley <dstanle@ibm.net>
Sender:       "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From:         Don Stanley <ibm.net@UNDEFINED.BITNET>
Organization: Advantis
Subject:      Re: Trapping data step error in AF

A useful technique for this sort of thing is to place each physical
datastep/proc step in a separate
submit block. This allows easy SCL programming to check the results of the step
and
then branch around unwanted blocks of code. Personally I find SCL much easier
to
do this than macro. You also have the advantage that you don't have to write
macro
code to prevent steps running -- RUN CANCEL or %if branches.. Also, you can do
useful
things at the step boundaries, for instance -- update a field that tells the
user how things
are going. I find masses of advantages to keeping as much in SCL as possible,
treating
SAS like an SCL addon. Of course if you are %including large programs into the
submit
this is more difficult.
 
Don
 
Jules Bosch <jules_bosch@CCMAIL.BMS.COM> writes:
 
>Sender: "SAS(r) Discussion" <SAS-L%VTVM1.BITNET@VTBIT.CC.VT.EDU>
>From: Jules Bosch <jules_bosch@CCMAIL.BMS.COM>
>Subject: Re: Trapping data step error in AF
>Lines: 7
>
>     Expanding (in thought only) on Andy Barnett's earlier post:
>
>     What about wrapping your data step code macros within the submit
>     block, using symput to capture the error condition at each boundary,
>     then testing the error macro var and either continuing or getting out
>     at that point.
>
>     Jules Bosch