Date:         Tue, 9 May 2006 16:41:22 -0400
Reply-To:     Joe Whitehurst <joewhitehurst@GMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Joe Whitehurst <joewhitehurst@GMAIL.COM>
Subject:      Re: Any way to recover from a Math Exception in a Proc embedded
              in a macro?
Comments: To: john.hixon@kodak.com
In-Reply-To:  <OFFE218EA7.006EA2FA-ON85257169.006EDA40-85257169.006FFA0D@knotes.kodak.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

John,

I have hunch that the problem may not happen with SAS Component
Language for two reasons.  First, SAS Component Language is 15 years
newer than the Macro Language, and I would bet SAS has learned a lot
from user experiences during that time.  Second, the Macro processor
will have already done its work before the SAS code executes and will
not be there to take over when the code fails as you have described.
In contrast, especially in iterative processing, control oscillates
between  SAS code (Procs, Datasteps) and SAS Component Language so if
the SAS code fails catastrophically, SAS Component Language will
resume control.  If you want to try an experiment, send me your tired
old troublesome macro code, and I will package it up in SAS Component
Language for you.  You will not need SAS/AF to execute, and, Randy
Herbison's discovery suggests you may be able to edit and recomile if
you should need to also without a SAS/AF license.

Joe

Joe

On 5/9/06, John Hixon <john.hixon@kodak.com> wrote:
> Ron says:
>
>
> >From:    "Fehd, Ronald J. (CDC/CCHIS/NCHM)" <rjf2@CDC.GOV>
> >Subject: Re: Any way to recover from a Math Exception in
> a Proc embedded in a macro?
>
> >PROC GenMod data  = GenModDataSet
> >           (where = (<Denominator> ne 0))
>
> >what do you think would be an appropriate action?
>
> >goback to the data cleansing step, right
>
> >Ron Fehd  the knot?zero?
>           or macro maven  CDC Atlanta GA USA RJF2 at cdc dot gov
> >
>
> Hi Ron,
>
> You must have missed the portion of my post that says:
>
> "My current code does all kinds of 'looking at the
> data' before it submits calls to iterative procs like MIXED,
> GENMOD, & GLIMMIX, in the hopes of not calling the Procs if
> the data are ill-conditioned.  This generally works well,
> but there are always new, "unthought of" data arrangements
> that cause the procs to throw exceptions. And, this is
> disastrous to the batch applications which rely on a macro
> loop to complete its execution for all "n" iterations.
> Typically, the macro loop is aborted, and the rest of the
> code fails."
>
> It is not as simple a "does the denominator = 0" when you call
> Stat Procs.  My code to "look at the data before calling the
> procs" is pretty elaborate, including looking for:
>
> 1)  Constant values of the response
> 2)  Constant values of the response across factor levels
> 3)  Poorly clustered data (data that has only 2-4 discrete values
> when calling Procs that expect continuous data, like Proc MIXED)
> etc etc.
>
> I just think that SAS needs to expose operating system errors
> that are generated from within their Procs (which are like
> "Black Boxes") so that we, as programmers, can respond to them.
>
> If SAS would not simply halt, and return an error code, then
> from within my macro I would be able to respond by simply
> plotting the offensive data with the message: "an [error code]
>  occurred during Proc xxxxxxx, no analysis possible."
>
> Then continue with the next n iterations of the macro.
>
> Best regards,
>
> John Hixon
> Eastman Kodak Company
> Rochester, NY USA
> 585-477-1984
>