For analysis, it's essentially a problem of 1) non-independence of observations, and 2) weighting of the multiple control groups in the analysis.  Below is assuming all of your matched cases from both control groups (combined) are unique observations--not duplicated.    The simplest solution, which is probably reasonable acceptable to most people, is likely to simply analyze the two sets of matched pairs separately, and present it as a "replication".  If the results are the same for both matched groups, then you can say the same result is achieved with propensity score matching even with an independent control group.  If the results are different, it would merit investigation as to whether the difference is due to detectable differences in the matched characteristics of the two control groups (or their difference-in-difference with the study group).  Such differences could emerge, and be observed, for example, if a first iteration of the propensity match is a "closer match" than the second iteration of propensity match.    Partial solutions, which I'm sure would be unsatisfactory to the scientific community (and to me), would be to:  a) code the two control groups (e.g. 1 vs. 0) into a variable and enter it as a covariate in a model using all the data, including the double study observations.  This would not solve the problem of non-independence, but would more-or-less ensure both control groups are weighted equally and fairly, removing any bias that snuck in from one propensity match iteration to the next.  b) Pool or average your responses from the two control groups into a single observation, as to be matched with a single observation of the study group.  This resolves the issue of non-independence, and partially ensures the control observations are weighted relatively equally; however, it definitely distorts the underlying true variance of observations in the control groups (which wouldn't necessarily be a problem if you had, say, 20 matched control groups, and could use their observed variance).    A slightly more complicated solution would be to construct a multilevel model.  There, you can enter the study group ID as the identifier for level-2, and the control group ID's as independent observations for level-1.  Since you would presumably be predicting level-2 outcomes from level-1 predictors, you could use a simple fixed-effects model (which is relatively simple, nice).  This should take care of both your issues of non-independence and comparative weighting of the multiple control groups in a single analysis.  Also, as in a) above, you could again code and enter propensity match iteration as a covariate in the model.      ... View more

I don't use ANOVA much.  But regression is essentially the same; I would just do a logistic account for the binary response.   proc logistic data= data; class factorA(ref='Silent') factorB(ref='Banana') / param=ref; model purchase(event='1') = factorA factorB factorA*factorB; run; To get the percentages is a bit more work.  You could do some lengthy code to get it, but I would probably just do this, and calculate the differences I wanted manually:    proc freq data= data; tables factorA * purchase; tables factorB * purchase; tables factorA * factorB * purchase; run;           ... View more

proc sql; create table id1 as select id1, salary from data; quit; proc sql; create table id2 as select id2, salary from data; quit; proc sql; create table wide as select a.*, b.salary as salary2, (a.salary + b.salary) as total_salary /* optionally: ,b.id2 */ from id1 a left join id2 b on a.id1 = b.id2; quit; There is probably an easier, less wonky way to do this, but here is a step by step approach that should work. This also assumes both ID's are the same format (num/char).  ... View more

proc sql; create table data1 as select distinct * from data; quit; proc sql; create table data2 as select *, count(code) as k from data1 group by id; quit; data data3; set data2; if k = 1; run; ... View more

Thanks, this is a good answer. My concern is a matter of interfacing with a database that has a 30 limit and preventing issues with exchange between systems. It seems manually checking may be the only option, then, and that is an elegant approach. ... View more

In my code, charvar is your original_variable, numvar is your new_variable. ... View more

I'm not familiar with that package, but the odds ratio is simply the square of the coefficient estimate. ... View more

There might be an easier way, but often in this situation I actually create a numeric var like so. I realize most people don't do this.   data want; set have; numvar = .; /* create "empty" numvar */ numvar = charvar; run; If you do this, the numvar will return blanks "." for any charvar entries that aren't actually a number.  So you can just pull up a list of the blanks, and review what they were in the corresponding charvar:   proc sql; create table numvar_blanks as select numvar, charvar from want where numvar = . /* optional */ and charvar ^= ''; quit; Once you've sorted out what to do with any wonky cases, you can just drop the charvar and rename the numvar as desired, perhaps in the first datastep.    ... View more

Unfortunately, it's a notorious problem with glimmix that it is a resource hog.  Even with relatively small samples, it will not be able to run unless it is hosted on a supercomputer.    Barring that, your best option might be to run the model on multiple, sufficiently small samples, and hope to observe consistency.  Of course, that probably wouldn't cut it for a peer-reviewed report, but may be useful for decision-making purposes based on the output.  ... View more

The abs() function actually did solve the problem! Still strange my method didn't work; but elegant solution; I appreciate it! ... View more

I'm making two lists:  one is a list of all the items (rows) that are >= .35 on at least one variable; the other is a list of items (rows) that are < .35 on all the variables.  Items (rows) with a highest value of  .346 on any variable end up on the list that is supposed to be >= .35.  ... View more

I narrated it as the opposite; the inaccurate flagging remains the issue. ... View more