Or more explicitly: Precede your PROC ANOVA step by  ods output OverallANOVA=oa; ods output ModelANOVA=ma; ods output Bartlett=ba; and you will find the p-values (together with more information) in datasets OA, MA and BA (or whatever you name them). ... View more

Good news for you, @aiaimanel!   Thanks a lot for providing the log files. This was the breakthrough.   As you've noticed, the pages where the errors were reported to have occurred (p. 223 and p. 229) are not part of the big log file, but of the small one, L18_1_log.txt. Even more confusingly, this log file contains several pages "twice"! More precisely: There are two different pages numbered 223 and two numbered 229 (and similar for other page numbers). In each case, one version is from 12:24 o'clock and the other from 12:28 o'clock today.   Indeed, errors were reported on pages 223 and 229 of 12:28, but not on the earlier pages with the same numbers from 12:24. What made them even harder to find was that they were one of the rare exceptions in SAS where errors are not denoted as "ERROR" in the log!   Please search for the string "NOTE 49-169" in the log. You will find two occurrences of this note (one on p. 223 and one on p. 229 of 12:28) saying that "The meaning of an identifier after a quoted string may change in a future SAS release. Inserting white space between a quoted string and the succeeding identifier is recommended."   These are just NOTEs, not ERRORs, but they are preceded by a code excerpt in which the string '0' is underlined and tagged with the number 49. Do you see these places? These underlinings and the number 49 would be printed in red (like errors!) if the log was shown in the log window rather than written to a file.   You can generate this type of error in a simple data step: data test; x=1; output; if 'A'='A'and 1 then put 'OK!'; x=2; output; run; As you can see, the data step creates the correct result: Dataset TEST is created correctly and "OK!" is written to the log, because the IF condition is true. The only issue SAS has with this code is that there is no blank between the closing single quote of the second 'A' and the operator "and". And just because the "meaning of an identifier after a quoted string might change in a future SAS release", it classifies this as an error, which eventually leads to the real "ERROR" message you found at the bottom of the large log file.   In your code it is the keyword "when" which should be separated by a blank from the preceding closing single quote of '0'. So, please add the blank at the appropriate places and all the notes "49-169" the "49"s and the final ERROR message will vanish. It's also good news that the "errors" were harmless and did not influence your results anyway.   Strangely enough, the same "error" is documented on p. 226 from 12:24 and was underlined and tagged with "49", but not commented with a note 49-169. I'm not sure why, but it seems that due to the absence of the NOTE, p. 226 was not mentioned in the list of pages where the errors occurred. Of course, you should insert the blank also in this place (if it was a separate place at all and not, e.g., macro code called several times). ... View more

According to the STATA documentation of their merge statement (http://www.stata.com/manuals13/dmerge.pdf), "m:m specifies a many-to-many merge and is a bad idea."   What they describe is exactly what happens in a SAS data step if you merge two datasets by a key with repeats of BY values in both datasets (i.e. one-to-one within the BY group, as pointed out by @Astounding, and repeating the last observation of the shorter BY group, if any).   In contrast, when PROC SQL joins two tables, it always creates a Cartesian product of the two tables (i.e. each row of the first combined with all rows of the second) as the internal "input to the rest of the query" (PROC SQL documentation, section "Joining Tables"). Please see @Astounding's example or the example "Full Outer Join" in the linked documentation.   So, if a BY group in table L has m observations and there is a matching BY group in table R with n observations, the STATA merge of the two tables would result in max(m,n) observations for that BY group, whereas the full outer join of PROC SQL would produce m·n observations. Please note that m·n > max(m,n) if and only if m>1 and n>1. Moreover, non-matching BY groups would be copied to the output dataset both in the STATA merge and the full outer join. That is, the difference of 10M vs. 300K observations that you observed implies that your datasets L and R have matching "BY groups" with non-unique keys (probably many of them).   Here's what the STATA documentation linked above says about such merges: "Because m:m merges are such a bad idea, we are not going to show you an example." "First, if you think you need to perform an m:m merge, then we suspect you are wrong." ... View more