LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (May 2006, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
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 >


Back to: Top of message | Previous page | Main SAS-L page