Date: Mon, 26 Apr 1999 09:34:14 -0700
Reply-To: Zeke Torres <sas_aholic@YAHOO.COM>
Sender: "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From: Zeke Torres <sas_aholic@YAHOO.COM>
Subject: Re: How to trick Proc Freq?
Content-Type: text/plain; charset=us-ascii
I implor you. I beg you. I beseech you. PLEASE.. PLEASE.. I am on my
knees crawling. PLEASE tell me where you work so I DO NOT APPLY for a
JOB there. I would NOT want to waste YOUR valuable 'TECHNICAL
MANAGERIAL" time and add ANY more grief to your "15 Years of
Do you have any printed material... IE publications? I need something
to prop up my desk at home. It seams to be slanted a little to the
Human, From: Universe, Milky Way Galaxy, Solar System, Earth, Nothern
Hemisphere, United States, Mid West, Illinois, Chicago, North side ah
you would know about it cause im sure your of a superior origination
OR wait am i being scarcastic?
--- david pider wrote:
> Alex Martchenko wrote:
> > Hi,
> > I have a credit policy SAS data set with almost 100 million
> >observations. It has a numeric variable FLDR_ID that can be any
> >integer number from -500,000 to +500,000. So on the average there
> >about 100 observations with the same FLDR_ID on the file. The data
> >set is sorted by a different variable (account number) and so it's
> >unsorted by FLDR_ID. I'm trying to create a data set with
> >frequencies, cumulative frequencies, percents and cumulative
> >for all values of FLDR_ID. I'm trying to use proc freq like that:
> > proc freq data=folders(keep=fldr_id);
> > tables fldr_id / missing out=fldr_fq;
> >But I have 2 problems: 1) proc freq runs out of memory and abends
> >the job 2) if I run it on a much smaller subset so it runs OK, it
> >doesn't create cumulative variables in the OUT= file. I could live
> >with problem 2 because I can read the output data set with frequency
> >and then calculate cumulatives in a data step.
> > Real pain is problem 1. I run it in batch on OS/390, 6.09E. A job
> >can only use 50M of memory (that's all system people say we can have
> >for a single SAS job). But proc freq wants more, so if I specify
> >MEMSIZE=100M it doesn't matter because after 50M limit is exceeded,
> >the job abends anyway.
> If you read SAS manuals you wouldn't be in trouble. About PROC FREQ,
> the manual says 'the maximum number of levels allowed for any one
> variable is 32,767. If you have a variable with more than 32,767
> levels, use the SUMMARY procedure'.
> >I know I can sort it by FLDR_ID and then use first. and last.
> >variables to do what I need. But in our system sorting 100 million
> >records is a big problem itself. Does anyone have suggestions? I
> >greatly appreciate any input.
> Here is one: if some of self appointed 'gurus' offer you a 'datastep
> algorithm' claiming it is 'more efficient' that SAS procs do yourself
> a favor and use 'delete' button. Trust my 15 years in SAS, none of
> thses 'solutions' run faster or 'more efficiently' than properly
> applied SAS procs. I've just fired one 'expert' as soon as I saw that
> he tried to get smart and summarized in datastep instead of proc
> summary. If I can't ban them 'gurus' from SAS profession, at least I
> can keep them away from my shop. And it's getting worse. Now this
> 'datastep approach' have even sneaked into SUGI. I almost fainted at
> seeing a paper by one of them 'gurus' (who I bet have no idea of real
> world programing) trying to replace proc sort with his 'quick sort'
> monstrosity. I wonder why he didn't call it 'blast sort' or
> BTW, try SQL too. Personally, I don't like it (it shouldn't of been
> SAS in the first place) but at least it's a SAS proc and at least
> beat any 'datastep algorithm' hands down.
> D. Pider
> Technical Manager
> 15 years of SAS experience
> Get Free Email and Do More On The Web. Visit http://www.msn.com
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com