This part of your log: Output Added: ------------- Name: ResidualNormalityPanel Label: Residual Normality Panel Template: ets.arima.Graphics.NormalityPanel Path: Arima.Estimate.ResidualNormalityPanel ------------- Looks like the ods object  you want is the same as @sbxkoenk's code used. Perhaps you can show the Log where you have the ODS OUTPUT statement with your model.   proc arima data=series_31; identify var=Yt(1) crosscorr=(X1t(1) X2t(1) X3t(1)) noprint; estimate q=1 input=( (1) X1t (1) X2t (1) X3t) method=ml; ODS OUTPUT ResidualNormalityPanel= work.yourdatasetname ; run; quit; I don't have access to Proc Arima so can't run the code. There might be that with procedures supporting run group processing like Proc Arima that the location of the ODS OUTPUT has to be within the run group.       ... View more

@sasalex2024 wrote: Dear Koen, Thank you very much for your response. Your code works perfectly for the example model you provided. However, I have been unable to adapt it to my specific case, which involves extracting residuals from a model with inputs and ARMA errors. I tried including the lines: *ods trace on; ods trace off; ODS output ResidualNormalityPanel=work.abc; before my PROC ARIMA code and ending with a quit; after the last run;. Unfortunately, this did not produce the dataset work.abc as expected. Would you be able to clarify if additional modifications are needed to make this approach work for models with inputs and ARMA errors? Thank you once again for your time and assistance! Run the trace on/off around your model code and show us the LOG. The log will include a bunch of bits with Names of the ODS objects created, include all of that along with the code and other messages the procedure generates. It may be that your install created a different ODS object than the ResidualNormalityPanel, or the spelling changed, from @sbxkoenk's install.   ODS TRACE ON; proc arima data=a; identify var=Yt crosscorr=(X1t X2t) noprint; estimate q=1 input=( (1) X1t (1) X2t ) method=ml; run; quit; ODS TRACE OFF;   ... View more

@quickbluefish wrote: If your program is a linear process that's meant to be run from top to bottom in its entirety (which I require everyone on my team to do) as opposed to highlighting and running chunks, then having the input and output dataset names the same is much more space-efficient, not to mention less likely to introduce errors (setting the wrong dataset). We do everything in Linux and launch everything from the command line. Your mileage may vary. Part of the bit around Macros is re-usability and the possibility of ending up in an Autocall library. Which is not conducive to relying on "top to bottom". I would say that is a pretty tight restriction on running code. ... View more

Since I run the example data set and get the same result as @Ksharp  AUDITOR_ cyear gvkey FKEY flag 2003 1161 2 1 2004 1161 2 1 2005 1161 2 1 2006 1161 2 1 2002 1380 2 0 2003 1380 2 1 2004 1380 2 1 2005 1380 2 1 2006 1380 2 1 2007 1380 2 0 2008 1380 2 0 2009 1380 2 0 2010 1380 2 0 2011 1380 2 0 2012 1380 2 0 2013 1380 2 0 2000 1913 1 0 2001 1913 1 0 2002 1913 1 0 2003 1913 1 0 Then one suspects something different about YOUR CC1 data set that we cannot distinguish because you are not providing example data as a working data step.   Instructions here: https://communities.sas.com/t5/SAS-Communities-Library/How-to-create-a-data-step-version-of-your-data-AKA-generate/ta-p/258712 will show how to turn an existing SAS data set into data step code that can be pasted into a forum code box using the </> icon or attached as text to show exactly what you have and that we can test code against.   ... View more

Your comment says "a macro var that contain names of fields (predictors) with comma between.". But the only place that you show a macro variable there are no commas. So which is it?   Note that in general with macro language the comma is the worst possible delimiter in macro values as they are quite likely to be interpreted as intention macro delimiters and generate errors in function or macro calls. Here is an example using @Kurt_Bremser second solution of the list without and with commas /* define a macro so missing macro definition isn't the error*/ %macro information_value (Var=); %put Parm is: &var; %mend; %let Predictor_Var_list=X R T; %macro all; %do i = 1 %to %sysfunc(countw(&predictor_var_list.)); %let param = %scan(&predictor_var_list.,&i.); %information_value(var=&param.); %end; %mend all; %all /* with comma list*/ %let Predictor_Var_list=X,R,T; %put Run with Predictor_Var_list= &Predictor_Var_list.; %all       @Ronein wrote: Hello Lets say that user define a macro var that contain names of fields (predictors) with comma between. Lets say that based on this macro variable should  run a macro. What is the way to run the macros automatically based on the user macro var?   %let Predictor_Var_list=X R T Q V S M W; %information_value(VAR=X); %information_value(VAR=R); %information_value(VAR=T); %information_value(VAR=Q); %information_value(VAR=V); %information_value(VAR=S);   ... View more

@Kurt_Bremser wrote: Two ways: from a DATA step: data _null_; do i = 1 to countw("&predictor_var_list."); call execute(cats('%nrstr(%information_value(',scan("&predictor_var_list.",i),'))')); end; run; from a macro: %macro all; %do i = 1 %to %sysfunc(countw(&predictor_var_list.)); %let param = %scan(&predictor_var_list.,i.); %information_value(&param.); %end; %mend all; %all Missing the & for I in the %scan.   I thought I was the only one that did that.... %let param = %scan(&predictor_var_list.,&i.); ... View more

Generic comment: Personally, macros are the worst place to use the same data set as source and output. Since the data step completely replaces the data set from the SET statement it can be a poor idea to begin with. In a macro it can be worse because you forget the possibility and don't realize that multiple calls to the macro can seriously affect the content. data someset; set someset; <other code> run; Second, since your %else loop does nothing except read the data set and rewrite it then all it does is waste clock cycles. Useless: %ELSE %DO; Data have; set have; Run; %END; And a style point, if this is close to the use point and not just testing general logic, your &ind_OOT value should be a parameter of the macro and not just appear in code assuming it was set.   ... View more

Sounds pretty clear, there is something in one or more variables in the input data that is invalid. With a message about characters I would suggest running proc freq on any of the character variables used in the model to see what might be consider invalid.   Note: ANY discussion of ERRORS should include 1) the LOG showing the code and all messages and 2) best would be to provide and example of data in the form of a working data step. The code is to head off all of the questions about variable type use, role in the model, dependent, independent, as well as options that may not interact well with each other. All of the messages are important because of the times SAS reports a problem and use of an alternate option in an attempt to get some result. The example data clarifies variable types and will help someone suggest which variables need to be looked at for likely problems.     ... View more

@Tom wrote: Having to do things like this makes it seems that you have issues in your upstream processes.  How did you end up with such a messy dataset?  What are you going to do with the resulting dataset? It does not look that useful for analysis.  What value do all of those observations with only missing values add??   I suspect it may be related to the https://communities.sas.com/t5/New-SAS-User/Fill-with-values-a-set-of-variables-to-reach-the-total/m-p/953701 bit where the "fill to value" was apparently to fix an incorrect count. Perhaps this data the index=0 with all the missing values are the "not an event" that the filled in values represented. I agree that this seems to represent a moderately flawed data structure at some point of the process. Look at https://communities.sas.com/t5/New-SAS-User/From-long-format-to-short-data-format/td-p/953512 for where the Variable1-Variable4 may have come from as well. ... View more

DIM is the function to return the defined size of an array. As other functions you must use the simple parentheses ( ) and not the brackets [ ] or braces { } around the argument of the function.       Instead of if (md{i} eq .p) then md{i}=-99; since you have multiple values assigned to the same recode: if (md{i} in (. .p .s) ) then md{i}=-99; I also hope this recode is only done for reporting or export purposes. Otherwise any statistic or calculations done with these variables will be terribly suspect in the result. ... View more

I would suggest using Proc SURVEYselect to select the ones for reassignment: Unfortunately you provided "example" as a picture, not a working data step or even text. The ID would be treated as a STRATA variable so for the procedure to work the data would have to be sorted by the id;   data have; input id count; /* create one observation per from summary for example data*/ do i=1 to count; output; end; drop i count; datalines; 1 3 2 2 3 8 4 10 ; proc surveyselect data=have out=selected outall samprate =(100 100 10 30); ; strata id; id id; run; The output data set has an added variable "selected" that can be used in a data step to do the adjustment. One way: data want; set selected; select (id); when (3) if selected=1 then id= 2; when (4) if selected=1 then id= 2; otherwise; end; drop selected selectionprob samplingweight; run; I am using a Select/When block instead of if/then/else as I am suspecting this process may get pushed to more than a couple of values of "Id" and the select is easier to keep straight in that case. Since your example has both assigning a value of 2 when (3,4) if selected=1 then id=2; could be used. The other way  would be more flexible for different assignments for different Id values.   You said 10% of the 3s. But only showed 4 values. So I'm not quite sure what you expect. The SAMPRATE is a percentage. You can use SAMPSIZE to specify a specific number. The SAMPRATE or SAMPSIZE should have one entry for each Strata when the rate/counts may different. Don't mix the size or rate, pick one. If you want all of the values for a strata then the rate is 100 (or 1) or size the number of observations for the id. With small numbers it is likely that the "rate" approach may not select any. 10% of 4 is 0.4 which would be the expected number of selected ID values of 3. Which means most likely not going to get any. ... View more

At a guess you need to find the definition code for the PLOTSTEP macro called towards the end of the code: %if "&plot"="yes" %then %do; %plotstep(plotdata=_tmc_allsp, xvar=timelist, yvar=Survival_comb, by=%str(&by &strata), trtvar=&trtvar, outfname=&plotfname, outpath=&plotpath); %end; The name Plotstep coupled with the condition makes me think that contains the actual plot code. Since the macro appears to use a data set created for plotting the plot may well not involve Proc Lifetest at all. So the %KM macros may not affect other code. Or Plotstep has it's own calls to the %KM macro variables that would override anything set prior the execution of the Plotstep macro. ... View more

This looks a lot like a report. If this is a report generated by SAS code you post the code?   It might be that the fix might be to update or create a custom format for the values of the original balance column.   @Kearthana1 wrote: If the loan count is 1 then merge to the next row. If last observation then merge with the previous row. Greatly appreciate your help in resolving this. Here is my data: Original Balance Loan Count Curr Balance Contrib IO Balance Contrib% WAC WAM (25,000 - 50,000] 1 116,294 7,412 0.0 4.47 317 (50,000 - 75,000] 12 711,046 43,812 0.2 4.52 337 (75,000 - 100,000] 33 2,906,308 186,190 0.8 4.49 331 (100,000 - 125,000] 24 2,651,113 144,296 0.6 4.48 332 (125,000 - 150,000] 1 5,807,462 383,168 1.7 4.51 331 (150,000 - 175,000] 59 9,304,718 643,080 2.9 4.52 329 (175,000 - 200,000] 83 15,377,836 984,286 4.4 4.50 342 (200,000 - 225,000] 69 14,498,236 889,785 4.0 4.50 340 (225,000 - 250,000] 84 19,678,015 1,278,485 5.7 4.50 340 (250,000 - 275,000] 76 19,644,538 1,156,395 5.2 4.50 339 (275,000 - 300,000] 1 20,128,657 1,117,135 5.0 4.50 343   Want: Original Balance Loan Count Curr Balance Contrib IO Balance Contrib% WAC WAM (25,000 -75,000] 13 827,340 51,224 0.2 4.50 327 (75,000 - 100,000] 33 2,906,308 186,190 0.8 4.49 331 (100,000 - 125,000] 24 2,651,113 144,296 0.6 4.48 332 (125,000 - 175,000] 60 15,112,180 1,026,248 2.3 4.52 330 (175,000 - 200,000] 83 15,377,836 984,286 4.4 4.50 342 (200,000 - 225,000] 69 14,498,236 889,785 4.0 4.50 340 (225,000 - 250,000] 84 19,678,015 1,278,485 5.7 4.50 340 (250,000 - 300,000] 77 39,773,194 2,273,530 5.1 4.50 341   ... View more

Which parts are you having problems with?   I know that the repeated column headers are going to have problems as that is not a normal request from Proc report though an Break Before with a computed block might do.   But sort orders for character values as dates are problematic as well. You will need a Variable to hold values like "Y22" as Proc Report doesn't do vertically stacked variables. Is the repeated header critical? If not, perhaps this would be sufficient and doesn't require rebuilding your data set: proc tabulate data= have; class type; class month/order=data; var Y22 Y23 Y24; table type*(Y22 Y23 Y24)*sum=''*f=best8., month /misstext=' ' ; run; ... View more