Thanks for your input and Ideas. I encountered the following scenario. I would like to know if this is possible.
I am running a PROC mixed procedure, before I ran, I am checking for Model structure type that fits for the data, if the convergence criteria won't meet then I am doing the alternative procedures.
Since I wanted a clean log, is it possible when convergence criteria won't meet, I want that log need to go into the different file, and the remaining should go to one file. is It possible to achieve. My aim is keep the log clean and at the same time have another log file. I am open to alternative options.
***************************************************************
***************************************************************
Code to create the QC1 dataset
***************************************************************;
***---MMRM ---***
%macro mmrm(var =);
*** Check if TYPE =UN works or not***;
/*options nonotes nosource DKROCOND = nowarn;*/
ods output convergencestatus=cs LSmeans=lsmn Diffs = LSMDiff FitStatistics = fit;
/*ods exclude all;*/
proc mixed data = qc1 method = reml;
class usubjid trtn avisitn agegroup;
model &var = trtn avisitn trtn*avisitn agegroup base /ddfm = kenwardroger solution;
repeated avisitn/subject=usubjid type=un;
lsmeans trtn*avisitn avisitn/diff cl;
run;
/*ods exclude none; /* Resume output */*/;
/*options notes source DKROCOND = warn;*/
******* ****************************************************************
Looking the above MMRM log have to be in different file
If convergence criteria met, then no issue; if not it is generating
Warnings in LOG
************************************************************************;
proc sql noprint;
select strip(upcase(reason)) into: criteria separated by "" from work.cs;
quit;
%put &criteria.;
%if %index(&criteria.,CONVERGENCE CRITERIA MET.) %then
%do;
ods output LSmeans=lsmn Diffs = LSMDiff FitStatistics = fit;
proc mixed data = qc1 method = reml;
class usubjid trtn avisitn;
model &var = trtn avisitn trtn*avisitn agegroup base /ddfm = kr;
repeated avisitn/subject=usubjid type=un;
lsmeans trtn*avisitn avisitn/diff cl;
run;
%end;
%else %do;
%let type = %str(CS TOEP AR);
%do ord = 1 %to 3;
ods output convergencestatus=cs LSmeans=lsmn Diffs = LSMDiff FitStatistics = fit;
proc mixed data = qc1 method = reml;
class usubjid trtn avisitn;
model &var = trtn avisitn trtn*avisitn agegroup base /ddfm = kr;
repeated avisitn/subject=usubjid type=%scan(&type,&ord) %if &ord=3 %then(1);;
lsmeans trtn*avisitn avisitn/diff cl;
run;
proc sql noprint;
select strip(upcase(reason)) into :criteria separated by "" from work.cs;
quit;
data data⩝
length type $20;
set fit;
if Descr='AIC (Smaller is Better)';
criteria="&criteria";
type="%scan(&type,&ord)";
run;
%end;
%end;
data all0;
set data1 data2 data3;
if index(criteria, 'CONVERGENCE CRITERIA MET.');
run;
proc sql;
select count(distinct criteria) into :nobs from all0;
quit;
proc sort data = all0;
by criteria value type;
run;
data all;
set all0;
by criteria value type;
if first.criteria;
run;
proc sql noprint;
select strip(upcase(type)) into :typemin separated by "" from work.all;
quit;
ods output LSmeans=lsmn Diffs = LSMDiff;
proc mixed data = qc1 method = reml;
class usubjid trtn avisitn;
model &var = trtn avisitn trtn*avisitn agegroup base /ddfm = kr;
%IF &typemin=%STR(AR) %THEN %LET typemin = ar(1);
repeated avisitn/subject=usubjid type=&typemin.;
lsmeans trtn*avisitn avisitn/diff cl;
run;
%mend;
%mmrm(var = aval);
@SASuserlot wrote:
Yes, The reason behind it is that the data is blinded now, So every time, we have to check which model will be suitable when new data is delivered. To check data every time, I created a macro to check (gatekeeping). My gate-keeping code causes the warnings in logs. If I know the data I will run the code separate and choose the right method.
Not sure what the blinded status has to do with this.
If you know that the log MIGHT generate WARNING statements then add your own NOTE or WARNING to the LOG so that users will not be confused by the WARNING into thinking the code did not work properly. Either generate the note before hand, or if you can detect the situations that generate the warning after the fact then conditionally generate the note when it applies.
Since I wanted a clean log
Splitting the log to have one log for models that converge and another log for models that don't converge is an odd request and if I was a cynical person, I would say it sounds a little underhanded to me. But maybe its not underhanded at all. Could you explain further the reasoning behind splitting logs like this?
Yes, The reason behind it is that the data is blinded now, So every time, we have to check which model will be suitable when new data is delivered. To check data every time, I created a macro to check (gatekeeping). My gate-keeping code causes the warnings in logs. If I know the data I will run the code separate and choose the right method.
@SASuserlot wrote:
Yes, The reason behind it is that the data is blinded now, So every time, we have to check which model will be suitable when new data is delivered. To check data every time, I created a macro to check (gatekeeping). My gate-keeping code causes the warnings in logs. If I know the data I will run the code separate and choose the right method.
Not sure what the blinded status has to do with this.
If you know that the log MIGHT generate WARNING statements then add your own NOTE or WARNING to the LOG so that users will not be confused by the WARNING into thinking the code did not work properly. Either generate the note before hand, or if you can detect the situations that generate the warning after the fact then conditionally generate the note when it applies.
@SASuserlot wrote:
Yes, The reason behind it is that the data is blinded now, So every time, we have to check which model will be suitable when new data is delivered. To check data every time, I created a macro to check (gatekeeping). My gate-keeping code causes the warnings in logs. If I know the data I will run the code separate and choose the right method.
Not sure I grasp what you are trying to say. But in any event, I still feel there might be (or might not be) underlying ethics issues here, and so I'm just going to stay out of this discussion.
Like @PaigeMiller I'd like to understand your purpose for splitting logs.
My purposes for having SAS logs are to:
Splitting logs would make my purposes just so much harder so that's why I'm interested in your purpose.
Thanks for responding. I provided some explanation for the @PaigeMiller response. Please let me know if it make any sense.
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.
Ready to level-up your skills? Choose your own adventure.