Date:         Sat, 17 Jul 2010 19:38:06 +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: hermans1@westat.com
In-Reply-To:  <FE10F31634E7F34B87AA143D596085415C07C1C2@EX-CMS01.westat.com>
Content-Type: text/plain; charset="iso-8859-1"

Sig,

 

It can get more complicated than that as some procedures will not create a background ods table unless one you ask for it and two what your asking can or is in the data.  An example of this is say Proc Univariate with missing observations.  If there are no missing values it will not produce the Missing ODS table even if you have that option specified in your Univariate code.  

 



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: Sat, 17 Jul 2010 14:57:32 -0400
> From: HERMANS1@WESTAT.COM
> Subject: Re: Why you should always use a RUN statement (A SAS Gotcha)
> To: SAS-L@LISTSERV.UGA.EDU
> 
> I've also found lately, perhaps related to sometime use of HTML or other output formats instead of purely lst output, that some statistical procedures' lst output doesn't appear in the DM OUTPUT window unless I put a QUIT statement after a RUN statement.
> S
> 
> -----Original Message-----
> From: SAS(r) Discussion [mailto: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
                                          
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2