| Date: | Fri, 3 Aug 2001 10:54:45 -0400 |
|---|
| Reply-To: | "H. Lawrence Hotchkiss" <larryh@ZEBRA.US.UDEL.EDU> |
|---|
| Sender: | "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU> |
|---|
| From: | "H. Lawrence Hotchkiss" <larryh@ZEBRA.US.UDEL.EDU> |
|---|
| Subject: | Re: SAS-L Digest - 3 Aug 2001 - Special issue (#2001-1002) |
|---|
|
| Content-Type: | X-sun-attachment |
|---|
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 1383
Hi,
Here's a short program that does the conversion. The file actually is
an ascii file, comma delimited, rather than an excel binary file. Excel
knows how to read these, so it looks like an excel file from excel. Sas
will read an excel file by using the correct engine. But since this is
not actually an excel file, I wrote up this short program to read it.
The program reads the variable names from the top line and the data from
the rest. To run it on your data, change the name of the input file
at the top, where it says "%let infile=data.csv;". Change "data.csv" to
the name of your file. You may have to put in the entire path, for
example "c:\breck\data\house.csv".
Copy the program into the sas program editor, then submit it. It should
work on most comma-delimited files in the format of this one. The only
limitation might be the width of the input data file and the number of
variables. These can be expanded if necessary.
I'm also attaching the output (both saslog and listing) from the run I did.
Larry
> From owner-SAS-L@listserv.uga.edu Fri Aug 3 10:20:51 2001
> Date: Fri, 3 Aug 2001 10:20:45 -0400
> Reply-To: "SAS(r) Discussion" <SAS-L@listserv.uga.edu>
> Sender: "SAS(r) Discussion" <SAS-L@listserv.uga.edu>
> From: Automatic digest processor <LISTSERV@listserv.uga.edu>
> Subject: SAS-L Digest - 3 Aug 2001 - Special issue (#2001-1002)
> To: Recipients of SAS-L digests <SAS-L@listserv.uga.edu>
> Content-Length: 46793
>
> There is one message totalling 1340 lines in this issue.
>
> Topics in this special issue:
>
> 1. Good Statistical Practice
>
> ----------------------------------------------------------------------
>
> Date: Fri, 3 Aug 2001 09:13:21 -0500
> From: Barbara Wilson <BWilson@RESPONSEONCOLOGY.COM>
> Subject: Re: Good Statistical Practice
>
> Thanks all - I found the 'Statistical Principles for Clinical Trials'
> recommended for adoption in 1998 by the International conference on
> Harmonization of Technical Requirements for Registration of Pharmaceuticals
> for Human Use at http://www.ifpma.org/ich5e.html#Design. This is the
> 'governing body' I was looking for. Barbara
>
> > ----------
> > From: John Jones
> > Sent: Friday, August 3, 2001 9:00 AM
> > To: Barbara Wilson; SAS-L@LISTSERV.UGA.EDU
> > Subject: Re: Good Statistical Practice
> >
> >
> > Barbara,
> >
> > You may find these sites useful... John
> >
> > http://www.fda.gov/cder/guidance/91698.pdf
> >
> > http://www.ifpma.org/ich1.html
> >
> >
> > At 08:22 AM 8/3/01 -0500, Barbara Wilson wrote:
> >
> >
> > I am a little confused. I am a Biostatistician involved in the
> > design and
> > analysis of clinical trials. I have heard of Good Clinical Practice,
> > but I
> > have never heard of a benchmark called Good Statistical Practice. Is
> > there
> > such a thing? What accrediting body governs such a thing? I found
> > nothing on
> > the ASA's web site, or the SCT web site. If following GSP will get
> > me $250K
> > - I'm all for it. Where can I buy the manual?
> >
> > Barbara
> >
> > > ----------
> > > From: Automatic digest processor
> > > Reply To: SAS(r) Discussion
> > > Sent: Thursday, August 2, 2001 6:30 PM
> > > To: Recipients of SAS-L digests
> > > Subject: SAS-L Digest - 2 Aug 2001 - Special issue
> > (#2001-998)
> > >
> > > There are 14 messages totalling 1006 lines in this issue.
> > >
> > > Topics in this special issue:
> > >
> > > 1. output Question
> > > 2. Output
> > > 3. Using SASFILE on WinNT 4.0 and Win2K
> > > 4. Stripping Codes when converting windows text file to unix (3)
> > > 5. filename options in infile ??
> > > 6. Skipping observations
> > > 7. filename options in infile ?? (Another Q)
> > > 8. Match-Merge a Small to Large Dataset (2)
> > > 9. RXPARSE, RXMATCH : storing pattern matches in sas variables
> > > 10. OT: Free Dmitry Sklyarov / DMCA (2)
> > >
> > >
> > ----------------------------------------------------------------------
> > >
> > > Date: Thu, 2 Aug 2001 16:53:59 -0400
> > > From: Dianne Rhodes <RHODESD1@WESTAT.COM>
> > > Subject: Re: output Question
> > >
> > > Dave Johnson's excellent paper presented at SUGI 26,
> > > Just the facts ma'am meets Is it Safe?
> > >
> > > http://www2.sas.com/proceedings/sugi26/p168-26.pdf
> > >
> > > Should give you ample examples of what you are looking for.
> > >
> > > > Darran Zenger <DZENGER@KLUNE.COM> asked
> > > > Subject: output Question
> > >
> > > > Is there a way to identify if there are 0 observations, then
> > create a
> > > > defaulted page (in html) that states that there is currently no
> > data for
> > > > this, else if, there IS data, go ahead and create a report/chart
> > with
> > > this
> > > > data? I'm assuming there is a way to identify if there is any
> > > observations
> > > > and if so, how do I do identify that?
> > >
> > > Dianne Louise Rhodes
> > > Sr. Systems Analyst
> > > Westat
> > >
> > > ------------------------------
> > >
> > > Date: Thu, 2 Aug 2001 13:40:28 -0700
> > > From: Peter Eberhardt <sasguy@VISTO.COM>
> > > Subject: Re: Output
> > >
> > > Darran:
> > > Here is a macro which returns the number of records in a table. It
> > also
> > > returns a -1 if the table does not exist.
> > >
> > > peter
> > >
> > >
> > > %macro RecsInDS(table);
> > > %local obs;
> > > %local handle;
> > > %local rc;
> > > %let handle = %sysfunc(open(&table));
> > > %if &handle
> > > %then
> > > %do;
> > > %let obs = %sysfunc(attrn(&handle, nlobs));
> > > %let rc = %sysfunc(close(&handle));
> > > %end;
> > > %ELSE
> > > %do;
> > > %let obs = -1;
> > > %end;
> > > &obs;
> > > %mend RecsInDS;
> > >
> > >
> > >
> > > %let rc = %recsinds(sameday);
> > > %put recs = &rc;
> > >
> > >
> > >
> > >
> > > If we torture the data long enough, they will confess.
> > > Thomas Mayer
> > > Economic Inquiry (1980)
> > >
> > __________________________________________________________________________
> > > _
> > > Visit http://www.visto.com.
> > > Find out how companies are linking mobile users to the
> > > enterprise with Visto.
> > >
> > > ------------------------------
> > >
> > > Date: Thu, 2 Aug 2001 13:48:31 -0700
> > > From: "E. Tan" <ponthy@YAHOO.COM>
> > > Subject: Using SASFILE on WinNT 4.0 and Win2K
> > >
> > > I have a program that use sasfile statement in the program.
> > >
> > > sasfile mwcs open ;
> > >
> > >
> > >
> > > On NT it works the way it should, i.e. load the dataset into the
> > > memory. However on Win-2K, I keep getting "ERROR: Invalid page
> > number
> > > 1 on file WORK.MWCS.DATA." Anyone experiencing the same thing?
> > SAS
> > > is v8.1 .
> > >
> > > Thanks for any input.
> > >
> > > ------------------------------
> > >
> > > Date: Thu, 2 Aug 2001 21:39:30 +0100
> > > From: Peter Crawford <Peter@CRAWFORDSOFTWARE.DEMON.CO.UK>
> > > Subject: Re: Stripping Codes when converting windows text file to
> > unix
> > >
> > > Karen Wyland <kwyland@PACBELL.NET> writes
> > > >I have a windows formatted text file which I want to read into
> > sas on
> > > >unix. As you may know, it carries either a line feed or return
> > code or
> > > >something at the end of each line. I see this when I view the
> > file in my
> > > >SAS on unix session.
> > > >
> > > >Is there an easy way to convert windows formatted text files to
> > unix
> > > format?
> > >
> > >
> > > Why worry ?
> > > on your infile statement just add a dlm option, like
> > > infile ............... dlm = '0D'x ;
> > >
> > > Then infile treats that carriage return character like normal
> > delimiters
> > >
> > >
> > >
> > > --
> > > Peter Crawford
> > >
> > > ------------------------------
> > >
> > > Date: Thu, 2 Aug 2001 21:45:43 +0100
> > > From: Peter Crawford <Peter@CRAWFORDSOFTWARE.DEMON.CO.UK>
> > > Subject: Re: filename options in infile ??
> > >
> > > Simple fix
> > > precede the filename statement with a length statement, to ensure
> > the
> > > target of the infile option filename= has enough room for both
> > path and
> > > name. The default $8 is seldom enough.
> > > And if you want to keep that filename in the output, you will have
> > to
> > > assign it to another variable, because the variables named as
> > infile
> > > options cannot be "keep"-ed
> > >
> > >
> > > try
> > > > data xx (keep=subj time x1-x6 where=(time ne .));
> > > > length subj $50
> > > fn $80 ;
> > > > infile fin ;
> > > > input @;
> > > infilename = fn ;
> > > > input lstr $varying200. len;
> > > > time=input(scan(lstr,1,','),time.);
> > >
> > >
> > >
> > > Huang, Ya <ya.huang@AGOURON.COM> writes
> > > >
> > > > Hi there,
> > > >
> > > > I am trying to read in multiple files using
> > > > filename with wildcard, also I want to know
> > > > where those records were from, so I used filename
> > > > option in infile statement, but the result only
> > > > show me the path of the file, for the
> > > > following example it showed c:\temp\,
> > > > I didn't get the filename part, which supposed
> > > > to be Subj10TxA.csv, Subj10TxB.csv, Subj10TxC.csv
> > > >
> > > > Anybody know what I am wrong here?
> > > >
> > > > Thanks
> > > >
> > > > Ya Huang
> > > >
> > > > ----------------------------
> > > >
> > > > filename fin "c:\temp\Subj10Tx*.csv";
> > > >
> > > > data xx (keep=subj time x1-x6 where=(time ne .));
> > > > length subj $50;
> > > > infile fin length=len filename=fn;
> > > > input @;
> > > > input lstr $varying200. len;
> > > > time=input(scan(lstr,1,','),time.);
> > > >
> > > > ....
> > > >
> > > >
> > > > subj=fn;
> > > > format time time.;
> > > > run;
> > > >
> > > > proc print;
> > > > run;
> > > >
> > > > The SAS System 12:35 Thursday, August 2, 2001 276
> > > >
> > > > Obs subj time x1 x2 x3 x4
> > x5
> > > > x6
> > > >
> > > > 685 c:\temp\ 11:40:00 1.9 1.7 1.7 1.6
> > 1.7
> > > > 1.7
> > > > 686 c:\temp\ 11:41:00 1.7 1.6 1.7 1.7
> > 1.7
> > > > 1.7
> > >
> > > --
> > > Peter Crawford
> > >
> > > ------------------------------
> > >
> > > Date: Thu, 2 Aug 2001 14:26:49 -0700
> > > From: Dale McLerran <dmclerra@MY-DEJA.COM>
> > > Subject: Re: Skipping observations
> > >
> > > David,
> > >
> > > If you will be repeatedly doing by group processing on the same
> > > dataset using a particular subset of the variables within the
> > > condition, and if the dataset is wide, then you can gain
> > efficiency
> > > by some preprocessing. The code below illustrates.
> > >
> > > First, we will create some data with a by variable (byvar) and a
> > > condition variable (x). In addition, we have 200 character
> > variables
> > > each of length 200. This gives us a wide file in which only a
> > couple
> > > of variables are needed to determine whether a variable should be
> > > output.
> > >
> > > data myfile;
> > > array avars {200} $200 a1-a200 (200*" ");
> > > do byvar=1 to 50;
> > > do j=1 to 100;
> > > x = ranuni(1234579);
> > > output;
> > > end;
> > > end;
> > > run;
> > >
> > >
> > > Now, I will construct some code which will select just the first
> > few
> > > records of myfile within each level of BYVAR. This is inefficient
> > > code like you previously presented. An efficient alternative will
> > be
> > > shown following that.
> > >
> > >
> > > data test1;
> > > set myfile;
> > > by byvar;
> > > if first.byvar then sumx=0;
> > > sumx+x;
> > > if sumx<5;
> > > run;
> > >
> > >
> > > Now, for the efficient alternative. Note that I must first strip
> > > off the variables BYVAR and X and place those variables in a
> > dataset
> > > which I name MYCOND. The subsequent datastep will be quite
> > efficient.
> > > It's relative efficiency will depend on how many observations are
> > > selected from dataset MYCOND relative to the number of records in
> > > MYFILE.
> > >
> > > data mycond;
> > > set myfile(keep=byvar x);
> > > run;
> > >
> > > data test2;
> > > /* determine which records are to be accepted using file MYCOND
> > */
> > > set mycond;
> > > by byvar;
> > > if first.byvar then sumx=0;
> > > sumx+x;
> > > if sumx<5 then do;
> > > /* Automatic variable _N_ is obtained from SET MYCOND
> > statement */
> > > /* Since _N_ represents a record number from MYCOND, and
> > record */
> > > /* numbers on MYCOND and MYFILE match, then we want to select
> > */
> > > /* record number _N_ from dataset MYFILE.
> > */
> > > set myfile point=_n_;
> > > output;
> > > end;
> > > run;
> > >
> > >
> > > The following code allows you to verify that the data extracted by
> > > the two alternative coding schemes is the same. (Note that we
> > have
> > > not sorted the data by BYVAR and SUMX. However, since the data
> > were
> > > generated by BYVAR, and since we accumulate positive valued X in
> > SUMX,
> > > then the data are already in the sort order needed to execute the
> > > datastep below.)
> > >
> > > data test3;
> > > merge test1
> > > test2;
> > > by byvar sumx;
> > > run;
> > >
> > >
> > > Since the efficient alternative requires preprocessing (stripping
> > > out the by variables and condition variables), efficiency is only
> > > realized if the condition dataset can be reused.
> > >
> > > Hope that this is of value to you.
> > >
> > > Dale
> > >
> > >
> > > >Date: Thu, 2 Aug 2001 14:51:51 GMT
> > > >Reply-To: David Rosenblatt <daver@TIBINC.COM>
> > > > David Rosenblatt <daver@TIBINC.COM> Skipping observations
> > > SAS-L@LISTSERV.UGA.EDU
> > > >I am a SAS novice so my apologies in advance if this question is
> > a
> > > >no-brainer. (If there's a good FAQ out there that has the
> > answers to
> > > >questions like these, please clue me in! )
> > > >
> > > >I just need to know if there's any kind of built-in method in SAS
> > that
> > > lets
> > > >you skip to the next group of observations in a data step once
> > you no
> > > longer
> > > >need to look at the remaining observations of the current group,
> > when
> > > >grouping via the BY keyword. ( Yes, it's easy enough to do this
> > using
> > > >"if's" to test all observations, but I'm wondering if there isn't
> > a more
> > > >efficient method.)
> > > >
> > > >For clarification, I'm looking for something to do this:
> > > >
> > > >data foo;
> > > > infile 'whatever';
> > > > by id;
> > > >
> > > > if <condition satisifed for this id> then do;
> > > > output;
> > > > <skip to next first.id>;
> > > > end;
> > > >run;
> > > >
> > > >
> > > >TIA,
> > > > Dave Rosenblatt
> > >
> > >
> > >
> > >
> > > ---------------------------------------
> > > Dale McLerran
> > > Fred Hutchinson Cancer Research Center
> > > mailto: dmclerra@fhcrc.org
> > > Ph: (206) 667-2926
> > > Fax: (206) 667-5977
> > > ---------------------------------------
> > >
> > > ------------------------------------------------------------
> > > --== Sent via Deja.com ==--
> > > http://www.deja.com/
> > >
> > > ------------------------------
> > >
> > > Date: Thu, 2 Aug 2001 14:28:44 -0700
> > > From: "Huang, Ya" <ya.huang@AGOURON.COM>
> > > Subject: Re: filename options in infile ?? (Another Q)
> > >
> > > This message is in MIME format. Since your mail reader does not
> > understand
> > > this format, some or all of this message may not be legible.
> > >
> > > ------_=_NextPart_001_01C11B9A.1B6E6DE0
> > > Content-Type: text/plain;
> > > charset="iso-8859-1"
> > >
> > > Thanks to Peter and also to Ron who responed offline.
> > >
> > > Now another question:
> > >
> > > Is this filename + "*.*" structure only work for SAS/Win?
> > >
> > > I just tried the same code in Unix, and got this error
> > > message:
> > >
> > > 1 filename fin "/db01/clin/ag1549/525/sas/data/*.csv";
> > > 2
> > > 3 data xx (keep=subj time x1-x6 where=(time ne .));
> > > 4 length subj fn $50;
> > > 5 infile fin length=len filename=fn;
> > > 6 input @;
> > > 7 input lstr $varying200. len;
> > > 8 time=input(scan(lstr,1,','),time.);
> > > 9 x1=input(scan(lstr,2,','),best.);
> > > 10 x2=input(scan(lstr,3,','),best.);
> > > 11 x3=input(scan(lstr,4,','),best.);
> > > 12 x4=input(scan(lstr,5,','),best.);
> > > 13 x5=input(scan(lstr,6,','),best.);
> > > 14 x6=input(scan(lstr,7,','),best.);
> > > 15
> > subj=compress(translate(scan(fn,3,'\'),'','SubjTx.csv'));
> > > 16 format time time.;
> > > 17 run;
> > >
> > > ERROR: Physical file does not exist,
> > /db01/clin/ag1549/525/sas/data/*.csv
> > >
> > >
> > > I know I can change it to a pipe:
> > >
> > > filename fin pipe "cat /db01/clin/ag1549/525/sas/data/Subj*.csv";
> > >
> > > But this way, I lost the filename.
> > >
> > > Any idea?
> > >
> > > Thanks
> > >
> > > Ya Huang
> > >
> > > ------_=_NextPart_001_01C11B9A.1B6E6DE0
> > > Content-Type: text/html;
> > > charset="iso-8859-1"
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > > <HTML>
> > > <HEAD>
> > > <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> > > charset=3Diso-8859-1">
> > > <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> > > 5.5.2653.12">
> > > <TITLE>RE: filename options in infile ?? (Another Q)</TITLE>
> > > </HEAD>
> > > <BODY>
> > >
> > > <P><FONT SIZE=3D2>Thanks to Peter and also to Ron who responed =
> > > offline.</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>Now another question:</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>Is this filename + "*.*" structure
> > only =
> > > work for SAS/Win?</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>I just tried the same code in Unix, and got this
> > =
> > > error</FONT>
> > > <BR><FONT SIZE=3D2>message:</FONT>
> > > </P>
> > >
> > > <P><FONT =
> > > SIZE=3D2>1 =
> > > filename fin
> > "/db01/clin/ag1549/525/sas/data/*.csv";</FONT>
> > > <BR><FONT =
> > > SIZE=3D2>2 =
> > > </FONT>
> > > <BR><FONT =
> > > SIZE=3D2>3
> > data =
> > > xx (keep=3Dsubj time x1-x6 where=3D(time ne .));</FONT>
> > > <BR><FONT =
> > > SIZE=3D2>4
> > length =
> > > subj fn $50;</FONT>
> > > <BR><FONT =
> > > SIZE=3D2>5
> > infile =
> > > fin length=3Dlen filename=3Dfn;</FONT>
> > > <BR><FONT =
> > > SIZE=3D2>6
> > input =
> > > @;</FONT>
> > > <BR><FONT =
> > > SIZE=3D2>7
> > input =
> > > lstr $varying200. len;</FONT>
> > > <BR><FONT =
> > > SIZE=3D2>8 =
> > > time=3Dinput(scan(lstr,1,','),time.);</FONT>
> > > <BR><FONT =
> > > SIZE=3D2>9 =
> > > x1=3Dinput(scan(lstr,2,','),best.);</FONT>
> > > <BR><FONT
> > SIZE=3D2>10 =
> > > x2=3Dinput(scan(lstr,3,','),best.);</FONT>
> > > <BR><FONT
> > SIZE=3D2>11 =
> > > x3=3Dinput(scan(lstr,4,','),best.);</FONT>
> > > <BR><FONT
> > SIZE=3D2>12 =
> > > x4=3Dinput(scan(lstr,5,','),best.);</FONT>
> > > <BR><FONT
> > SIZE=3D2>13 =
> > > x5=3Dinput(scan(lstr,6,','),best.);</FONT>
> > > <BR><FONT
> > SIZE=3D2>14 =
> > > x6=3Dinput(scan(lstr,7,','),best.);</FONT>
> > > <BR><FONT
> > SIZE=3D2>15 =
> > > subj=3Dcompress(translate(scan(fn,3,'\'),'','SubjTx.csv'));</FONT>
> > > <BR><FONT
> > SIZE=3D2>16 =
> > > format time time.;</FONT>
> > > <BR><FONT
> > SIZE=3D2>17 =
> > > run;</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>ERROR: Physical file does not exist, =
> > > /db01/clin/ag1549/525/sas/data/*.csv</FONT>
> > > </P>
> > > <BR>
> > >
> > > <P><FONT SIZE=3D2>I know I can change it to a pipe:</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>filename fin pipe "cat =
> > > /db01/clin/ag1549/525/sas/data/Subj*.csv";</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>But this way, I lost the filename.</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>Any idea?</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>Thanks</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>Ya Huang</FONT>
> > > </P>
> > >
> > > </BODY>
> > > </HTML>
> > > ------_=_NextPart_001_01C11B9A.1B6E6DE0--
> > >
> > > ------------------------------
> > >
> > > Date: Thu, 2 Aug 2001 14:48:28 -0700
> > > From: "Huang, Ya" <ya.huang@AGOURON.COM>
> > > Subject: Re: Stripping Codes when converting windows text file to
> > unix
> > >
> > > This message is in MIME format. Since your mail reader does not
> > understand
> > > this format, some or all of this message may not be legible.
> > >
> > > ------_=_NextPart_001_01C11B9C.DD812100
> > > Content-Type: text/plain;
> > > charset="iso-8859-1"
> > >
> > > What if the file is comma delimited, so we should have
> > > infile ... dlm=',' it conflict with dlm='0D'x?
> > >
> > > >
> > > > Why worry ?
> > > > on your infile statement just add a dlm option, like
> > > > infile ............... dlm = '0D'x ;
> > > >
> > > > Then infile treats that carriage return character like normal
> > > > delimiters
> > > >
> > > >
> > > >
> > > > --
> > > > Peter Crawford
> > > >
> > >
> > > ------_=_NextPart_001_01C11B9C.DD812100
> > > Content-Type: text/html;
> > > charset="iso-8859-1"
> > >
> > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > > <HTML>
> > > <HEAD>
> > > <META HTTP-EQUIV="Content-Type" CONTENT="text/html;
> > charset=iso-8859-1">
> > > <META NAME="Generator" CONTENT="MS Exchange Server version
> > 5.5.2653.12">
> > > <TITLE>RE: Stripping Codes when converting windows text file to
> > > unix</TITLE>
> > > </HEAD>
> > > <BODY>
> > >
> > > <P><FONT SIZE=2>What if the file is comma delimited, so we should
> > > have</FONT>
> > > <BR><FONT SIZE=2>infile ... dlm=',' it conflict with
> > dlm='0D'x?</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2>> </FONT>
> > > <BR><FONT SIZE=2>> Why worry ?</FONT>
> > > <BR><FONT SIZE=2>> on your infile statement just add a dlm
> > option,
> > > like</FONT>
> > > <BR><FONT SIZE=2>> infile ............... dlm
> > = '0D'x
> > > ;</FONT>
> > > <BR><FONT SIZE=2>> </FONT>
> > > <BR><FONT SIZE=2>> Then infile treats that carriage return
> > character
> > > like normal </FONT>
> > > <BR><FONT SIZE=2>> delimiters</FONT>
> > > <BR><FONT SIZE=2>> </FONT>
> > > <BR><FONT SIZE=2>> </FONT>
> > > <BR><FONT SIZE=2>> </FONT>
> > > <BR><FONT SIZE=2>> --</FONT>
> > > <BR><FONT SIZE=2>> Peter Crawford</FONT>
> > > <BR><FONT SIZE=2>> </FONT>
> > > </P>
> > >
> > > </BODY>
> > > </HTML>
> > > ------_=_NextPart_001_01C11B9C.DD812100--
> > >
> > > ------------------------------
> > >
> > > Date: Thu, 2 Aug 2001 16:51:39 -0500
> > > From: "Kitzmann, Daniel J." <kitzmann.daniel@MAYO.EDU>
> > > Subject: Match-Merge a Small to Large Dataset
> > >
> > > Dear SAS-Lers:
> > >
> > > Just soliciting advice on the preferred approach to the following
> > problem:
> > >
> > > I want to match-merge a SMALLd dataset (~10,000 obs) containing a
> > unique
> > > KEYv variable with a series of LARGEd datasets (each ~2M obs),
> > which
> > > contain
> > > multiple records with repeats on the same KEYvs. The desired
> > MERGEd
> > > dataset
> > > will contain all records, including repeats on KEYv, from LARGEd
> > that
> > > match
> > > on KEYv in SMALLd.
> > >
> > > I've been reading the SAS-L archive literature on Key-Searching
> > and
> > > Hashing,
> > > chiefly those posts of Paul Dorfman, as well as the relevant
> > published
> > > SUGI
> > > papers. I am pleased to report that I think I am, for an
> > autodidact
> > > programmer anyway, gradually albeit laboredly acquiring a
> > verstehen for
> > > that
> > > is going on and why. Before proceeding too far, however, I just
> > want to
> > > confirm that I am looking down the apt alley here.
> > >
> > > Some additional facts: I'm working in the OS/390 batch
> > environment. KEY
> > > is
> > > indeed an integer, and even though the number of KEYv obs in
> > SMALLd is
> > > merely around 10,000, KEYv's theoretical range spans seven digits.
> > Am I
> > > correct in therefore supposing that the Coalescing List Hashing is
> > the
> > > method to employ? Thank you kindly in advance.
> > >
> > > Cordially,
> > > Dan
> > > kitzmann.daniel@mayo.edu
> > >
> > > ------------------------------
> > >
> > > Date: Thu, 2 Aug 2001 15:59:36 -0600
> > > From: Jack Hamilton <JackHamilton@FIRSTHEALTH.COM>
> > > Subject: Re: RXPARSE, RXMATCH : storing pattern matches in sas
> > variables
> > >
> > > What I would suggest is changing the way the function is called.
> > Instead
> > > of having 4 arguments, RXCHANGE could have 4 or more arguments.
> > When
> > > called with 4 arguments, it would perform exactly as it does now.
> > >
> > > The additional arguments would be string variables, one for each
> > value you
> > > want returned.
> > >
> > > An earlier example used
> > >
> > > -----
> > > if _n_ = 1 then do;
> > > * the =n in the TO is the nth un-named tagged match
> > expression;
> > > rx = rxParse ("first=<:?>.<:?>'@'<:?>.:? TO
> > =first','=1','=2");
> > > end;
> > >
> > > call rxChange (rx, 999, addr, normalized);
> > > first = scan (normalized,1,',');
> > > last = scan (normalized,2,',');
> > > comp = scan (normalized,3,',');
> > > -----
> > >
> > > My suggest would replace the second section of code with
> > >
> > > -----
> > > call rxChange (rx, 999, addr, normalized, first, last);
> > > -----
> > >
> > > I think this is easier to understand. I would think it would
> > easier to
> > > implement as well, since it wouldn't require the supervisor to
> > parse the
> > > rxparse string for variable names.
> > >
> > > Come to think if, I don't understand how the suggestion below
> > could
> > > possibly work - the rxparse string might not have been available
> > to the
> > > supervisor at run time, and consequently it couldn't be parsed for
> > > variable names.
> > >
> > > What I would really like is the elimination of the rx variable -
> > the SAS
> > > supervisor should keep track of that kind of internal information,
> > just as
> > > it does with the LAG function. That could be implemented without
> > breaking
> > > any existing uses of the regular expression functions.
> > >
> > >
> > >
> > >
> > > --
> > > JackHamilton@FirstHealth.com
> > > Development Manager, Technical Group
> > > METRICS Department, First Health
> > > West Sacramento, California USA
> > >
> > >
> > > >>> "Mike Rhoads" <RHOADSM1@WESTAT.COM> 07/27/2001 5:54 AM >>>
> > > A "little birdie" has confirmed what Richard DeVenezia and I
> > posted
> > > yesterday -- the "variables" created in RXPARSE pattern
> > expressions are
> > > used
> > > only within the expression and have no connection to DATA step
> > variables.
> > > Thus, in Richard Patterson's original example, you cannot extract
> > company
> > > name from an e-mail address simply by putting something like
> > > CompanyName=<^'@.'*> into your pattern.
> > >
> > > Some thought is being given to adding this functionality in a
> > future
> > > version
> > > of SAS. One question that comes up is whether all or only some of
> > the
> > > RX-variables should become DATA step variables, and how to control
> > this.
> > > I
> > > suggested the following:
> > >
> > > OPTIONS RXVAREXPORT = NONE | ALL | NAMED;
> > >
> > > NONE is self-explanatory, and should be the installation default
> > so
> > > current
> > > programs don't break (by suddenly acquiring unexpected variables).
> > ALL
> > > would export all of the RX variables, whether the pattern was
> > named or
> > > not,
> > > using the _1, _2 convention for unnamed patterns. NAMED would
> > only export
> > > variables that are explicitly named (which is what I would
> > normally
> > > prefer).
> > >
> > > Other ideas are more than welcome!
> > >
> > > Mike Rhoads
> > > Westat
> > > RhoadsM1@Westat.com
> > >
> > > ------------------------------
> > >
> > > Date: Fri, 3 Aug 2001 08:31:00 +1000
> > > From: Hockey Richard <rhockey@MATER.ORG.AU>
> > > Subject: Re: OT: Free Dmitry Sklyarov / DMCA
> > >
> > > This type of logic would see photocopiers, tape recorders, cameras
> > and
> > > even
> > > pen and paper being illegal! All technologies which have been used
> > to
> > > overcome other technologies used by publishers of copyrighted
> > material.
> > > Cheers
> > > RH
> > >
> > > > -----Original Message-----
> > > > From: John Whittington [ mailto:John.W@MEDISCIENCE.CO.UK]
> > > > Sent: Thursday, 2 August 2001 7:34 AM
> > > > To: SAS-L@LISTSERV.UGA.EDU
> > > > Subject: Re: OT: Free Dmitry Sklyarov / DMCA
> > > >
> > > >
> > > > At 08:58 01/08/01 -0700, Jeff Voeller wrote (in part):
> > > >
> > > > >By mentioning DVD, Karsten has raised a situation where
> > sometimes the
> > > > >"protection" actually renders the product worthless. As I
> > > > understand it,
> > > > >the person who cracked the DVD encryption scheme did not do
> > > > it in order to
> > > > >make illegal copies, but rather because there was _no_ way
> > > > at the time to
> > > > >play a DVD on a Linux system. In other words, a Linux user
> > with a
> > > > >legitimately purchased DVD drive and a legitimately purchased
> > DVD was
> > > > >forbidden to actually access the DVD content because it was
> > > > "protected"
> > > > >into uselessness.
> > > >
> > > > Hmmmm. I'm not sure that I have all that much sympathy with
> > > > the plight of
> > > > someone who purchases 'data' in a format that is incompatible
> > > > with his/her
> > > > equipment! In this particular case, it is the 'encryption
> > > > scheme' that
> > > > creates the incompatibility - but that makes it no more
> > > > sensible for the
> > > > persob to purchase data in an incompatible format than if the
> > > > incompatibility were a physical one.
> > > >
> > > > >My point: There are indeed times when it's completely
> > > > legitimate to defeat
> > > > >a copy protection scheme and do so without in any way
> > > > stealing data or
> > > > >denying a copyright holder legitimate proceeds.
> > > >
> > > > Yes, I accept that there are times when the reason for
> > > > wanting to 'defeat a
> > > > copy protection scheme' are totally innocent, and would harm
> > > > no-one. However, as I've said before, the whole concept of
> > 'copy
> > > > protection' goes out of the window the moment there is free
> > legal
> > > > availability of a means of circumnavigating that protection.
> > > > It is by no
> > > > means without precedent that the illegitimate intentions of a
> > > > few (maybe
> > > > not quite so few :-) can result in frustrating or
> > > > inconvenient restrictions
> > > > upon the innocent.
> > > >
> > > > As I asked Karsten, I think I also need to ask you whether
> > > > what you are
> > > > really asking for is the total abolition of 'copy protection'?
> > > >
> > > > Kind Regards,
> > > >
> > > >
> > > > John
> > > >
> > > > ----------------------------------------------------------------
> > > > Dr John Whittington, Voice: +44 (0) 1296 730225
> > > > Mediscience Services Fax: +44 (0) 1296 738893
> > > > Twyford Manor, Twyford, E-mail: John.W@mediscience.co.uk
> > > > Buckingham MK18 4EL, UK mediscience@compuserve.com
> > > > ----------------------------------------------------------------
> > > >
> > > >
> > >
> > > ------------------------------
> > >
> > > Date: Thu, 2 Aug 2001 23:27:44 +0100
> > > From: Peter Crawford <Peter@CRAWFORDSOFTWARE.DEMON.CO.UK>
> > > Subject: Re: Stripping Codes when converting windows text file to
> > unix
> > >
> > > the dlm= option can take a constant with more than one character
> > > %let Hcomma = %sysfunc( putc( %str(,), $hex2));
> > > * because I don't want to remember the hex for comma on this
> > platform !;
> > > infile ... dlm="0D&Hcomma"x ;
> > >
> > > In message
> > <79A739F5800AD411B65E00D0B741D3B102644D23@currency.agouron.co
> > > m>, Huang, Ya <ya.huang@agouron.com> writes
> > > >
> > > > What if the file is comma delimited, so we should have
> > > > infile ... dlm=',' it conflict with dlm='0D'x?
> > > >
> > > > >
> > > > > Why worry ?
> > > > > on your infile statement just add a dlm option, like
> > > > > infile ............... dlm = '0D'x ;
> > > > >
> > > > > Then infile treats that carriage return character like
> > normal
> > > > > delimiters
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Peter Crawford
> > > > >
> > >
> > > --
> > > Peter Crawford
> > >
> > > ------------------------------
> > >
> > > Date: Thu, 2 Aug 2001 18:51:45 -0400
> > > From: "Dorfman, Paul" <Paul.Dorfman@BCBSFL.COM>
> > > Subject: Re: Match-Merge a Small to Large Dataset
> > >
> > > Daniel,
> > >
> > > With so few lookup keys and relatively short (1E7) key range,
> > there is a
> > > number of possibilities, depending on your system resources.
> > >
> > > 1. If you have plenty of memory, use the key-indexed search. To
> > account
> > > for
> > > 1E7 possible numeric keys, you need a numeric array sized as
> > [0:9999999],
> > > each cell taking up 8 bytes of memory. On my current Real
> > Computer, the
> > > test step below maxs out at 82 Mb:
> > >
> > > 1 DATA _NULL_ ;
> > > 2 ARRAY A(10000000) _TEMPORARY_ ;
> > > 3 RUN ;
> > > NOTE: The DATA statement used 0.23 CPU seconds and 83989K.
> > >
> > > If your system people are OK with you using a region of about 100
> > Mb
> > > region
> > > (just to be on the sure side, have enough memory left for buffers,
> > etc.),
> > > then go with the key-indexing: It is both simplest and by far the
> > fastest
> > > seraching method. Actually, at my current site, I have been using
> > up to 1
> > > Gb
> > > for a single SAS batch - so far, unpunished.
> > >
> > > 2. Of course, on *your* system, your system folks can say 'Fat
> > chance'.
> > > Then
> > > you may recall that binary information (present-absent in this
> > case) does
> > > not have to be stored in 8 bytes, i.e. 64 bits. It can be safely
> > plugged
> > > in
> > > just 1 bit. Potentially, it saves you 64 times the memory compared
> > to the
> > > key-indexing. In S/390 reality, it happens to be 56, for it is how
> > many
> > > bits
> > > the mantissa of a numeric SAS variable has on the mainframe, and
> > that is
> > > all
> > > that can be used (leave the exponent alone!). To bitmap 1E7
> > consecutive
> > > integers, we need 1E7 bits, i.e. 1.2 Mb, that is, nothing. You can
> > find
> > > ready-to-go bitmapping code precisely matching your task both in
> > SUGI 26
> > > and
> > > in sas-l archives.
> > >
> > > Bitmap will work slightly slower than the key-indexed table, for
> > it
> > > requires
> > > more computations. However, it has advantages, too. If your key
> > extends 1
> > > digits, it would be no big deal, and a 12 Mb bitmap will swallow
> > it with
> > > no
> > > problem; and you can handle even 9 digits if there is 120 Mb to
> > use
> > > (pretty
> > > much trifle nowadays). You can store the bitmap in a file, and
> > then simply
> > > load it in memory as necessary when subsetting the next file.
> > >
> > > 3. Then, of course, you can hash. With only 10,000 lookup keys,
> > there is
> > > no
> > > need to resort to more memory-efficient, but also more complex,
> > coalecsed
> > > list collision resolution policy designed to handle relatively
> > tight
> > > tables.
> > > Instead, you can set the load factor as low as 0.1 (that is, make
> > the
> > > table
> > > 90% sparse) and practically guarantee that you will have no
> > collisions at
> > > all to resolve! In such a situation, the simplest collision
> > resolution
> > > policy, linear probing, will work just fine - and be fastest, too,
> > since
> > > it
> > > is less computationally intensive than both link listing and
> > double
> > > hashing.
> > > Once again, in the paper, you will find code applied to your
> > situation (I
> > > actually used exactly this sort of task to demonstrate/compare
> > different
> > > direct-addresing lookup methods).
> > >
> > > 4. I see nothing wrong with compiling the 10,000 lookup keys in a
> > format
> > > via
> > > CNTLIN= and using the latter to search for each key coming from
> > the
> > > "large"
> > > file. With so few keys, the format compile time and its memory
> > consumption
> > > are insignificant (they become extremely significant when the
> > number of
> > > keys
> > > starts exceeding ~100,000.) And even though formats search slower
> > than a
> > > very sparse hash table, it might be much less noticeable if the
> > task is
> > > I/O
> > > bound - for example, if the "large" file has a long "tail".
> > >
> > > 5. Finally, you can simply use SQL equijoin and specify a large
> > > BUFFERSIZE=.
> > > I bet that already as low as with BUFFERSIZE=100000, the SQL
> > optimizer
> > > will
> > > decide to memory-hash the 10,000 keys for you and effectively use
> > the
> > > method
> > > you have in mind - automatically. Specify the system option
> > MSGLEVEL=I and
> > > _METHOD option on the SQL. If in the log you see SQXJHSH among
> > "the SQL
> > > execution methods chosen", that is it. Again, the SQL's internal
> > hash will
> > > not work as fast as hand-coded hashes (especially key-indexing),
> > but it
> > > will
> > > run faster than a format, and then - heck, you have got virtually
> > nothing
> > > to
> > > code!
> > >
> > > Kind regards,
> > > ======================
> > > Paul M. Dorfman
> > > Jacksonville, Fl
> > > ======================
> > >
> > > -----Original Message-----
> > > From: Kitzmann, Daniel J. [ mailto:kitzmann.daniel@MAYO.EDU]
> > > Sent: Thursday, August 02, 2001 5:52 PM
> > > To: SAS-L@LISTSERV.UGA.EDU
> > > Subject: Match-Merge a Small to Large Dataset
> > >
> > >
> > > Dear SAS-Lers:
> > >
> > > Just soliciting advice on the preferred approach to the following
> > problem:
> > >
> > > I want to match-merge a SMALLd dataset (~10,000 obs) containing a
> > unique
> > > KEYv variable with a series of LARGEd datasets (each ~2M obs),
> > which
> > > contain
> > > multiple records with repeats on the same KEYvs. The desired
> > MERGEd
> > > dataset
> > > will contain all records, including repeats on KEYv, from LARGEd
> > that
> > > match
> > > on KEYv in SMALLd.
> > >
> > > I've been reading the SAS-L archive literature on Key-Searching
> > and
> > > Hashing,
> > > chiefly those posts of Paul Dorfman, as well as the relevant
> > published
> > > SUGI
> > > papers. I am pleased to report that I think I am, for an
> > autodidact
> > > programmer anyway, gradually albeit laboredly acquiring a
> > verstehen for
> > > that
> > > is going on and why. Before proceeding too far, however, I just
> > want to
> > > confirm that I am looking down the apt alley here.
> > >
> > > Some additional facts: I'm working in the OS/390 batch
> > environment. KEY
> > > is
> > > indeed an integer, and even though the number of KEYv obs in
> > SMALLd is
> > > merely around 10,000, KEYv's theoretical range spans seven digits.
> > Am I
> > > correct in therefore supposing that the Coalescing List Hashing is
> > the
> > > method to employ? Thank you kindly in advance.
> > >
> > > Cordially,
> > > Dan
> > > kitzmann.daniel@mayo.edu
> > >
> > >
> > >
> > > Blue Cross Blue Shield of Florida, Inc., and its subsidiary and
> > > affiliate companies are not responsible for errors or omissions in
> > this
> > > e-mail message. Any personal comments made in this e-mail do not
> > reflect
> > > the views of Blue Cross Blue Shield of Florida, Inc.
> > >
> > > ------------------------------
> > >
> > > Date: Fri, 3 Aug 2001 00:27:20 +0100
> > > From: John Whittington <John.W@MEDISCIENCE.CO.UK>
> > > Subject: Re: OT: Free Dmitry Sklyarov / DMCA
> > >
> > > At 11:35 02/08/01 -0700, Karsten M. Self wrote (in part):
> > >
> > > >Would you buy a book that you could only read in an XYZ Co.
> > certified
> > > >bookreader?
> > >
> > > If I did not have such a reader, of course I wouldn't - any more
> > than I
> > > would buy a book written in a language I couldn't understand or a
> > video I
> > > couldn't play on a UK VCR into a UK TV or software on media for
> > which I
> > > didn't have the appropriate drive/whatever - and that was
> > precisely my
> > > point.
> > >
> > > >Why should you need to fit the bookreader to the book?
> > > >You've *bought* the book.
> > >
> > > But, as I said, I would NOT buy the book if I knew that I didn't
> > have the
> > > means to read it. Wiould you buy a PAL video cassete if all you
> > had to
> > > view videos with was US equipment?
> > >
> > > >Additional points: you're assuming that the consumer is aware of
> > the
> > > >limitations of the medium or work purchased. In the case of the
> > eBook,
> > > >and a CD copy prevention technolgy from MacroVision, this hasn't
> > been
> > > >the case. Restrictions of the medium are only made known after
> > the
> > > >purchase is completed. Turns out that this is against the law...
> > >
> > > Good point, and it certainly is highly desirable that the consumer
> > should
> > > be made aware of this (and here speaks a stupid English tourist
> > who DID
> > > once buy a non-PAL video in Florida!). As for being against the
> > law, it
> > > probably would also be contrary to our 'Trade Descriptions Act'.
> > However,
> > > the remedy available under that law would be to refund one's
> > purchase cost
> > > if one had been mislead into buying something one could not use.
> > >
> > > > > .... However, as I've said before, the whole concept of 'copy
> > > > > protection' goes out of the window the moment there is free
> > legal
> > > > > availability of a means of circumnavigating that protection.
> > > >
> > > >Not true, and missing several important points. I'm responding
> > to this
> > > >point in my more considered reply to your prior post.
> > >
> > > I'm not sure what points you think I'm missing, or which
> > 'considered
> > > reply'
> > > you refer to - is that the post to which I've already responded,
> > and to
> > > which response you are replying to here?
> > >
> > > I'm sorry, but it still seems pretty 'obvious' to me that there is
> > little
> > > point in having 'copy protection' if a legal means of
> > circumnavigating
> > > that
> > > protection is freely available. I'm obviously missing something -
> > what
> > > advantages are there in having a copy protection system which can
> > be
> > > overcome by a freely available and legal means? If you knew that
> > a legal
> > > means of opening and driving your car was freely available to
> > anyone who
> > > wanted to, would you bother to lock it?
> > >
> > > Kind Regards,
> > >
> > >
> > > John
> > >
> > > ----------------------------------------------------------------
> > > Dr John Whittington, Voice: +44 (0) 1296 730225
> > > Mediscience Services Fax: +44 (0) 1296 738893
> > > Twyford Manor, Twyford, E-mail: John.W@mediscience.co.uk
> > > Buckingham MK18 4EL, UK mediscience@compuserve.com
> > > ----------------------------------------------------------------
> > >
> > > ------------------------------
> > >
> > > End of SAS-L Digest - 2 Aug 2001 - Special issue (#2001-998)
> > > ************************************************************
> > >
> > >
> >
> > John T. Jones -- Phone: (910) 509-4814 -- JonesJ@PharmaResearch.com
> >
> > Rise above the obstacles in life and focus on the positive...
> > ... for the measure given is the measure you will receive....
> >
> >
>
> ------------------------------
>
> End of SAS-L Digest - 3 Aug 2001 - Special issue (#2001-1002)
> *************************************************************
>
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: readcsv.sas
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 23
* readcsv.sas: Read comma-delimited file into sas. *;
%let infile=data.csv;
data _null_;
length vname $32 line $200;
length vlist $1200;
infile "&infile" dlm=',' dsd obs=1 lrecl=200 pad;
input line $char200.;
do j=1 to 1000;
vname=scan(line,j);
if vname = "" then leave;
vlist=trim(vlist)||" "||vname;
output;
end;
call symput("vlist",vlist);
run;
data csvfile;
infile "&infile" dlm=',' dsd firstobs=2 lrecl=200 pad;
input &vlist;
run;
proc means maxdec=4; run;
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: readcsv.log
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 96
1 The SAS System 10:33 Friday, August 3, 2001
NOTE: Copyright (c) 1999 by SAS Institute Inc., Cary, NC, USA.
NOTE: SAS (r) Proprietary Software Version 8 (TS M0)
Licensed to UNIVERSITY OF DELAWARE, Site 0002866009.
NOTE: This session is executing on the SunOS 5.7 platform.
This message is contained in the SAS news file, and is presented upon
initialization. Edit the files "news" in the "misc/base" directory to
display site-specific news and information in the program log.
The command line option "-nonews" will prevent this display.
NOTE: SAS initialization used:
real time 0.23 seconds
cpu time 0.09 seconds
NOTE: AUTOEXEC processing beginning; file is /home/zebra/larryh/autoexec.sas.
NOTE: AUTOEXEC processing completed.
1 * readcsv.sas: Read comma-delimited file into sas. *;
2
3 %let infile=data.csv;
4
5 data _null_;
6 length vname $32 line $200;
7 length vlist $1200;
8 infile "&infile" dlm=',' dsd obs=1 lrecl=200 pad;
9 input line $char200.;
10 do j=1 to 1000;
11 vname=scan(line,j);
12 if vname = "" then leave;
13 vlist=trim(vlist)||" "||vname;
14 output;
15 end;
16 call symput("vlist",vlist);
17 run;
NOTE: The infile "data.csv" is:
File Name=/home/zebra/larryh/Users/BreckRobinson/data.csv,
Owner Name=larryh,Group Name=staff,
Access Permission=rw-------,
File Size (bytes)=4867003
NOTE: 1 record was read from the infile "data.csv".
The minimum record length was 81.
The maximum record length was 81.
NOTE: DATA statement used:
real time 0.02 seconds
cpu time 0.03 seconds
18
2 The SAS System 10:33 Friday, August 3, 2001
19 data csvfile;
20 infile "&infile" dlm=',' dsd firstobs=2 lrecl=200 pad;
21 input &vlist;
22 run;
NOTE: The infile "data.csv" is:
File Name=/home/zebra/larryh/Users/BreckRobinson/data.csv,
Owner Name=larryh,Group Name=staff,
Access Permission=rw-------,
File Size (bytes)=4867003
NOTE: 64603 records were read from the infile "data.csv".
The minimum record length was 22.
The maximum record length was 82.
NOTE: The data set WORK.CSVFILE has 64603 observations and 12 variables.
NOTE: DATA statement used:
real time 5.01 seconds
cpu time 2.17 seconds
23 proc means maxdec=4; run;
NOTE: There were 64603 observations read from the dataset WORK.CSVFILE.
NOTE: The PROCEDURE MEANS printed page 1.
NOTE: PROCEDURE MEANS used:
real time 1.42 seconds
cpu time 0.66 seconds
NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414
NOTE: The SAS System used:
real time 6.76 seconds
cpu time 2.95 seconds
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: readcsv.lst
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 20
The SAS System 1
10:33 Friday, August 3, 2001
The MEANS Procedure
Variable N Mean Std Dev Minimum Maximum
----------------------------------------------------------------------------
YEAR 64603 2001.0000 0.0000 2001.0000 2001.0000
MSA 64603 3356.5316 2931.1173 0.0000 9360.0000
STATE 64603 29.3522 16.2194 1.0000 78.0000
COUNTY 64603 87.7583 103.6365 1.0000 840.0000
CTRACT 64603 322727.6226 395326.1072 100.0000 999999.0000
TOTPOP 62986 4675.3025 4593.7518 1.0000 165304.0000
UNEMPL 61951 151.7773 173.5136 1.0000 4598.0000
MEDINC 62508 35009.6103 16293.2020 2825.0000 167434.0000
AGEHOUSE 62650 28.6389 13.1548 1.0000 51.0000
PCTPUBL 61330 0.0510 0.0589 0.0006 1.0000
PCTVACT 61807 0.1029 0.1062 0.0009 1.0000
PCTOWN 62067 0.5871 0.2121 0.0010 1.0000
----------------------------------------------------------------------------
|
