Regarding the WARNING statement: The WARNING is suggesting that you specify the <repeated-effect> in the REPEATED statement; see the documentation REPEATED statement. It would be something like   repeated mth / subject=blk*fert*nfix*id type=sp(pow)(c-list);   where c-list is a numeric variable (which means it would not appear in the CLASS statement).   Regarding CONTRAST and ESTIMATE statements: This paper addresses your questions in detail. In particular, consider using the LSMESTIMATE statement rather than the CONTRAST or ESTIMATE statement; LSMESTIMATE makes writing contrasts and estimates easier and less error-prone.   You didn't ask, but I would think that if you want to analyze growth "rate", then you would need to apply an appropriate regression model for the response over time. But I know essentially nothing about your study design or the definitions of your variables, so this is just speculation on my part.   ... View more

Actually it’s an implicit OR, not AND when you likely wanted an AND. This may seem pedantic but it’s an important differentiation. ... View more

@AaronJ wrote: I'm using SAS University and i copied and pasted a program into a new program window, gave it a name etc. It's ready to run. I run just the import statement, it imports it fine. I run the data statement, it runs just fine. However, when i try to run the Proc Univariate statement, i get: "Variable GLDcm in list does not match type prescribed for this list." It's just a column of numbers in an excel file. The same type of file, with the same type of columns of numbers, ran just fine in the other program, but now it won't run. However, if i convert GLDcm to logGLD using the logGLD=log(GLDcm); statement, then the Proc Univariate runs fine. I want to see if the untransformed data is normally distributed, so i don't want to do logGLD if it's not necessary. 1) Why won't SAS University recognize the column of data GLD_cm? if that can't be resolved,  2) how can i un-transform the logGLD back into regular numbers so that SAS will read the data?   Here's the code as i have it now: %web_drop_table(WORK.IMPORT); FILENAME FILEREF '/folders/myfolders/TreeGrowth.xlsx'; PROC IMPORT DATAFILE=FILEREF DBMS=XLSX OUT=WORK.IMPORT; GETNAMES=YES; RUN; data TreeGrowth; set import; if Hgt="Ht"; logGLD=log(GLDcm); logDBH=log(DBHcm); logHeight=log(Height); run; /*proc print data=TreeGrowth; run;*/ proc univariate Normal Plot data=TreeGrowth; var GLDcm logGLD; Histogram GLDcm logGLD/Normal; QQPLOT GLDcm logGLD; output out=AllEvents; run; ......................................... Thanks for the help Excel doesn't force types on fields so SAS has to guess and with any guesses, it can be wrong. For example, if your file has a few missing first it will assume its character. If it has NA or . it may also assume it is missing. Some options to fix this: Make sure the cell is formatted as numeric in Excel and that there are no characters in any of the values.  Convert the file to a CSV and import it that way. Use GUESSINGROWS=MAX or check the code and customize it to import the file with the types you need. You can use INPUT() to convert the value to a numeric, but make sure to save it to a new name. new_num = input(old_name, 8.);   ... View more

Although you say "GLM", I see that you are using MIXED which is a better choice. I typically use GLIMMIX rather than MIXED because it has more nice bells and whistles, like making interaction plots from the LSMEANS statement and doing letter assignments to pairwise mean comparisons.   Does PLOTID identify the subplot?   Your Q1: I doubt there is anything wrong with DATE2 coding. When you slice the FERT*NFIX*DATE2 interaction by FERT*NFIX, you get a contrast with 8 df that tests H0: all DATE2 means equal for a particular combination of FERT and NFIX. If this contrast is significant, then there is evidence that at least one date differs from at least one other, which as you note does not help much with interpretation of a 3-way interaction.   In my opinion, pairwise comparisons are of limited use in interpretation of interaction. I prefer to build contrasts that are sensible in context, i.e., that reflect important research questions. For example, I might build a set of contrasts to compare the FERT*NFIX interactions pairwise among levels of DATE2. Is the interaction on date 1 different than the interaction on date 2, or on date 3, etc. You can control family-wise error rate among these comparisons if need be. This paper is a good resource for this coding   https://support.sas.com/resources/papers/proceedings11/351-2011.pdf   Your Q2: I'm not sure that I'm interpreting your question correctly, so you may need to elaborate.   You can do pairwise comparisons among interaction means with Type I error control, but it is not at all desirable. Say that FERT has 3 levels, NFIX has 2 levels, and DATE2 has 9 levels, hence 3x2x9 = 54 means and 1431 (!) pairwise comparisons. Tukey will control for 1431 tests, most of which are of no interest to you because they compare something like F1_N1_D1 to F3_N2_D8. So you lose a tremendous amount of (if not essentially all) power by controlling for a set of comparisons that is much too big. If for some insane reason, you wanted to do that anyway, or just see how it turns out, use    lsmeans fert*nfix*date2 / diff adjust=tukey lines; Other thoughts:   Q: Why have you included BLOCK*FERT*DATE2 in the RANDOM statement rather than pooling it into residual error?    Q: Is compound symmetry (TYPE=CS) the best choice for covariance among 9 dates?   ... View more

thanks, i think you and i caught that at the same time. I tried to delete this post, but SAS told me i didn't have sufficient privileges.  Again, thanks for pointing out the error. ... View more

No problem!   So, Mixed (as well as all other Stat Procs, im pretty sure) is just going to ignore those records that have blank fields that are either in your: Response or model variables.    It will give you a warning note like: "Some observations are not used in the analysis because of missing fixed effects (n=10)"   shouldn't be a big deal though, unless you're missing a ton of records.  ... View more

Yup, that worked. Thanks. ... View more