How about this? data numbers; input value; format value2 dollar18.2; value2=round(value,.1); cards; 12.3456 98.7654 56.7890 265456234.3645 ; run; proc print; run; ... View more

I don't see the reason to use a macro. Why not just use one of these (it's not clear from your post whether you want a new dataset, a printout, or some other result)? proc print data=one noobs; where sale >= 200; run; or data two; set data one; where sale >= 200; run; or data one; input id sale amt; if sale >= 200 then output; cards; 101 150 4500 102 200 5500 103 210 6000 ; ... View more

Thanks. Your idea worked well for me after tweaking it a bit. Here's what I ended up with: data work.a (drop=i cell); infile "delimited.txt" dlm='09'X dsd missover lrecl=2048; do i = 1 to 71; input cell :$16. @; if i = 13 then Identifier = cell; if i = 71 then Value = input(cell, 8.); end; output; run; Still, I thought there was a way to move the pointer by a number of delimiters so that this could all be written as one input statement (no loops or if-then steps). ... View more

I think a CASE statement would work. proc sql; select case when Component_Product_ID = . then ICIS_Product_ID else Component_Product_ID end as Pseudo_Pr_ID from . . . quit; ... View more

One easy solution is to record the original order in a separate variable before sorting and merging. Then, you can resort on this separate variable back to the original order. data a; set a; order +1; run; proc sort data=a; by var1; run; proc sort data=b; by var1; run; data combined; merge a b; by var1; run; proc sort data=combined; by order; run; ... View more

How about using the HAVING statement in PROC SQL? You could do this all in one step with something like proc sql; create table person, job from step01 group by person having enddate = max(enddate); quit; ... View more

I'm not an expert, but I'll start things off anyway. Unix is an operating system while EG and 9.1.3 are SAS software products. SAS runs on Windows or Unix (or other platforms) so if you want to use SAS and you want to use the Unix operating system, then you buy and install a Unix version of SAS v9.1.3. The issue may be more about a preference to write custom scripts rather than use EG. This may be in part because of the very structured formatting of the tables and listings for clinical trials. I haven't used EG, but I think I know enough about it that I wouldn't ignore this product for getting you through 75% of the required programming. The issue may also be about comfort level. I've done some SAS programming for clinical trials and have used SAS 9.1.3 on Windows without any resistance or complaints. The preference for Unix may also be related to the OS on which the programmers 'grew up'. There are some benefits to using an OS that 1) programmers are comfortable with and 2) may be more compatible with other data sources or software products. ... View more

Try this: ***DEFINE BASELINE HDL,LDL,TRIG VARIABLES.; data jessica.baseline; merge jessica.cholesterol_base jessica.dosing; by subject; if dosedate - sampdate <= 5 and dosedate - sampdate > 0 then output; run; * This has to be a separate DATA step in order for the BY variable to work properly.; data jessica.baseline; set jessica.baseline; by subject; retain b_hdl b_ldl b_trig; if first.subject then do; b_hdl=.; b_ldl=.; b_trig=.; end; if hdl ne . then b_hdl = hdl; if ldl ne . then b_ldl = ldl; if trig ne . then b_trig = trig; keep subject b_:; if last.subject then output; run; proc print data=jessica.baseline; run; ... View more

I would suggest not renaming the hdl, ldl and trig variables, but assigning the value when the date criteria is met. When the dosedate - sampdate is less than or equal to 5, then assign the hdl, ldl and trig values to b_hdl, b_ldl, and b_trig. Here's and example: data jessica.baseline; merge jessica.cholesterol_base jessica.dosing; by subject; keep subject b_:; if dosedate - sampdate <=5 then do; b_hdl=hdl; b_ldl=ldl; b_trig=trig; end; run; proc print data=jessica.baseline; run; Is this what you're looking for? ... View more

Have you tried this: data X; merge D (in=a) C (in=b); by common_var; if b; run; The "if b" should return only records where C has a record. I've also found good success with PROC SQL and the LEFT JOIN / RIGHT JOIN / FULL JOIN functionality. I seem to recall that the way a DATA step and SQL merge is different, so sometimes one might be better suited to your application. ... View more

I second the recommendation of SAS® Programming in the Pharmaceutical Industry. I bought this book and found it extremely helpful with my first clinical trial programming project. This book has great detail and since clinical trial analyses are pretty standardized, all the examples are useful. ... View more

Maybe this is getting off topic, but wouldn't it be better to create a copy of the master data set and sort that "working" copy? I haven't analyzed many clinical trial datasets, but for the few that I have done, I set up the original SAS datasets in a read-only library and make copies when I have to manipulate data. Also, some procedures don't require sorting. You could use the CLASS statement instead of the BY statement for some PROCs. For reporting results, I've used an approach where I determine order using a numeric column (you really have to know what the rows will be) and then order the data as part of the DEFINE statement in a PROC REPORT procedure. ... View more

Thanks for the info and suggestions. I did a few calculations to check whether a 4GB file size seems appropriate. My six variables are $32, $15, 8, $1, 8, 8 in length for a total of 72 bytes per row. 56x10e6 rows x 72 bytes per row / 1.07x10e9 bytes per GB is about equal to 3.8GB. The character formats are as small as they can be, but you're right that I could reduce two of these to just 8 bytes if I use numeric values with a format. If I replace two of the character values with numeric values (and create a format for each of the unique character strings), my six variables would still come to 41 bytes per row which calculates to about 2.1GB. This is too close to the limit for my comfort. ... View more