Date:         Fri, 16 Jul 2010 18:20:46 +0000
Reply-To:     toby dunn <tobydunn@HOTMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         toby dunn <tobydunn@HOTMAIL.COM>
Subject:      Re: Why you should always use a RUN statement  (A SAS Gotcha)
Comments: To: jfh@stanfordalumni.org
In-Reply-To:  <CE23EAFE-8D21-464B-9B7E-C89E91D4AFEF@alumni.stanford.org>
Content-Type: text/plain; charset="iso-8859-1"

I agree with Jack, I hate when people place titles inside of their procedure code.  Its freaking Global for crying outloud.  By placing them inside of the Proc code people get the wrong impression it is Local to that Proc and end up with them bleeding over in other reports that they never intended it for.  Ending step boundaries are a must, any thing short of using them is simply stupid.    

Toby Dunn 

"Don't bail. The best gold is at the bottom of barrels of crap." 
Randy Pausch
 
"Be prepared. Luck is where preparation meets opportunity." 
Randy Pausch



 
> Date: Fri, 16 Jul 2010 10:23:34 -0700
> From: jfh@STANFORDALUMNI.ORG
> Subject: Re: Why you should always use a RUN statement (A SAS Gotcha)
> To: SAS-L@LISTSERV.UGA.EDU
> 
> I disagree. I put titles before the item they print for, as a form of documentation. And I would not omit the RUN under any circumstances. In addition to making titles work better, RUN makes the SAS log appear in the right place, and omitting it my cause problems with ODS output.
> 
> 
> --
> Jack Hamilton
> jfh@alumni.stanford.org
> Caelum non animum mutant qui trans mare currunt.
> 
> 
> 
> 
> On Jul 16, 2010, at 9:01 , Fehd, Ronald J. (CDC/OCOO/ITSO) wrote:
> 
> > yes, it is one of the major hassles of going up the learning curve of
> > SAS
> >
> > for the record
> > while titles are indeed global,
> > since they are retained across step boundaries,
> > they need to be -understood- as local to step.
> >
> > your problems will be solved by placing appropriate titles
> > -after- the proc statement:
> >
> >> title 'Predicted values';
> >>
> >> proc print data = schooler.anxdepitt;
> >> title2 'AnxDepITT';
> >
> >> *run;*now superfluous;
> >>
> >> proc print data = schooler.disorgitt;
> >> title2 'DisOrgITT';
> >
> >> run;
> >
> >
> > Ron Fehd the macro maven CDC Atlanta GA USA RJF2 at cdc dot gov
> >
> >> -----Original Message-----
> >> From: owner-sas-l@listserv.uga.edu [mailto:owner-sas-
> >> l@listserv.uga.edu] On Behalf Of Peter Flom
> >> Sent: Friday, July 16, 2010 11:30 AM
> >> To: SAS-L@LISTSERV.UGA.EDU
> >> Subject: Why you should always use a RUN statement (A SAS Gotcha)
> >>
> >> Hello all
> >>
> >>
> >>
> >> OK, there are lots of places where it's written that using RUN
> >> statements
> >> makes code look cleaner, but that invocation of another PROC statement
> >> makes
> >> the previous PROC get submitted. So.. It sounds like that RUN
> >> statement is
> >> a sort of esthetic extra.
> >>
> >>
> >>
> >> Well, it just bit me. Luckily, we found the error before doing
> >> anything
> >> really bad, because some of the results were ridiculous. But
> >>
> >>
> >>
> >> I had this
> >>
> >> title 'Predicted values';
> >>
> >> title2 'AnxDepITT';
> >>
> >> proc print data = schooler.anxdepitt;
> >>
> >> run;
> >>
> >> title2 'DisOrgITT';
> >>
> >> proc print data = schooler.disorgitt;
> >>
> >> run;
> >>
> >> title2 'HostExcITT';
> >>
> >> proc print data = schooler.hostexcitt;
> >>
> >> run;
> >>
> >> title2 'NegativeITT';
> >>
> >> proc print data = schooler.negativeitt;
> >>
> >> run;
> >>
> >> title2 'PositiveITT';
> >>
> >> proc print data = schooler.positiveitt;
> >>
> >> run;
> >>
> >>
> >>
> >> etc. only without the RUN statements other than the final one. And
> > the
> >> title2 are NOT where I would have thought they would go; rather, the
> >> title2
> >> for anxdepitt is disorgitt, and so on.
> >>
> >>
> >>
> >> Now that I've found the error, I sort of see why it happened. But I
> >> don't
> >> find it intuitive at all. And it took me quite a while to find the
> >> problem.
> >>
> >>
> >>
> >> So .. Always use RUN.
> >>
> >>
> >>
> >> Have others been bitten by this one?
> >>
> >>
> >>
> >> Peter
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Peter Flom PhD.
> >>
> >> Peter Flom Consulting LLC
> >>
> >> 5 Penn Plaza, Ste 2342
> >>
> >> NY NY 10001
> >>
> >> www.statisticalanalysisconsulting.com
> >>
> >> www.IAmLearningDisabled.com
                                          
_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3