Hi Steve This sounds like it works out the same as doing the combination in the DATA step.....That' smy intuition anyway.  Do you know if my intuition is right?   Peter ... View more

I would do 2).   This seems a lot simpler.  The original intent was to do one thing, but it didn't work out that way (so often the case) so iI think you have to adjust. ... View more

@PGStats  Yes, I know it exists.  But .... I think I heard this in a SGF talk long ago:   If you merge without a by You'll get strange results and won't know why ... View more

You need a BY on your MERGE.  This should be the variable that matches between the data sets (ID number or whatever).  If no variable matches between data sets then any results you get will be nonsense. ... View more

You are right that you have dependent data because "time to satiety" will partly depend on the person.   RM ANOVA is one way to analyze such data, and it can be done in SAS, but RM ANOVA makes rather strong assumptions (it assumes sphericity) and a better way to analyze such data is with multilevel models.  Since your DV is continuous, then PROC MIXED is probably a good place to start. ... View more

If you can stratify then you can put the IF statement outside the PROC.  That is, essentially, what stratification does.   What exactly are you trying to do?  ... View more

In this paper by Kiernan, Tao and Gibbs (all with SAS), there is a section about this error.   I tried to cut and paste that section, but the formatting got all messed up.   ... View more

Well, certainly type is going to cause problems with all those IVs to be used.  You can either drop that type or try to combine it with another.   Beyond that, I think you need to also look at the IVs and their distribution. ... View more

I think your first task is to figure out just how sparse the data are and the first step within that is to find out the distribution of type.  If it is fairly evenly distributed among your 600,000 cases then you have approximately 1500 cases per level of type, which is not sparse at all.  However, if some levels of type have very few members, you might want to combine levels.  You can also do the same for all your other variables.   Next, to get an overall sense of sparseness, the /LIST option on PROC FREQ can be very helpful, something like:   PROC FREQ data = mydata;   TABLE type*kind*weekday*psum*rsum*dp*vnet*dep*dsum*dret*dnet/LIST; RUN:   However, this may produce too many rows to look at, in which case you can do it by smaller sets of variables.   The statistical technique should, I think, be multinomial logistic (as you suspected).  There are exact methods to deal with sparse tables, but they will take preposterous amounts of time with N = 600,000.  However, HPLOGISTIC may offer some savings of time, depending on your exact setup (see the documentation). ... View more

You've gotten some good advice regarding MEANS.  Especially the advice to BE CAREFUL.   In your question, though, you used MEANS only as an example.  If you  want to do regression, I suggest either QUANTREG or ROBUSTREG.   Oddly enough, I wrote a paper on these. Should more of your PROC REGs be QUANTREGs and ROBUSTREGs?   In addition, note that the outliers are often the interesting stuff - automatically excluding outliers would mean that we never discovered black holes. :-). ... View more

Ok, time to talk to tech support. I'll report back on what they say. ... View more

Interesting!  But that's surely a problem? I know that QUANTREG is sensitive to high leverage points.  But the extent of the sensitivity (and whether it is problematic) surely doesn't depend on whether one requests particular plots! ... View more