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:   Wed, 10 May 2006 12:44:21 -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" <john.hixon@kodak.com>
In-Reply-To:   <OF8317F4C0.9195AC50-ON85257169.0072B255-85257169.0072E943@knotes.kodak.com>
Content-Type:   text/plain; charset=ISO-8859-1; format=flowed

John,

I had another thought about your problem. I think it is possible to generate an error that will crash the whole SAS session, and, in that case, SCL will be just as useless as the Macro Language. If you have SAS/Connect you can rsubmit the code (1 step at a time) asynchronously to another SAS session on the same machine using MP Connect technology using loops inside a SAS Component Language program or even the ancient SAS Macro Language (but not quite as ancient as DOS by about a year) and then test for the successful execution of the step. If the session executing the code crashes, you can programmtically determine the reason, fix the problem and start another session and rersubmit the step that failed.

Joe

On 5/9/06, john.hixon@kodak.com <john.hixon@kodak.com> wrote: > > > Thanks, Joe. > > Will do. > > But, it will have to be 2morrow AM. > > I will send you a small macro and some data that makes Proc GenMod fail. > > If it is possible to capture the failure, and code around it via SCL, > then you have made a new convert. :-) > > > Best regards, > > John Hixon > Eastman Kodak Company > Rochester, NY USA > 585-477-1984 > > > > > > *"Joe Whitehurst" <joewhitehurst@gmail.com>* > > 05/09/2006 04:41 PM > To > john.hixon@kodak.com cc > SAS-L@listserv.uga.edu > Subject > Re: Any way to recover from a Math Exception in a Proc embedded in a > macro? > > > > > > 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