Usually the problem with reading an Excel file created by SAS is caused by SAS not actually putting any information into the file.  Make sure that the step that actually writes to the XLS file has written at least one observation with at least one variable.   Also XLS files have smaller limits on number of rows (observations) and columns (variables) than modern XLSX files allow.  Perhaps your data exceeds one or both of those limits. ... View more

What exactly is generating that error message? Because it sounds like something that would be generated by a program that was trying to READ the file.  Please share you SAS log so we can see the exact error.   Also do you really need to create the ancient XLS format?  Try switching to the XLSX format and see if that works better for you. proc export data=sample dbms=xlsx outfile="/home/raju/filename.xlsx" replace ; run; ... View more

So part of the problem is that you cannot divide the pie into an infinite number of slices. I am not sure what the physical limit is but since you are asking for a pie with 1,003 slices we can probably assume it is less than 1000. ... View more

Use of the SF-12 is governed by QualityMetric which is now IQVIA. https://coas.iqvia.com/COAs/sf-12v2-health-survey-standard   Here is a website from RAND Health Care with information including that PDF scan of the SF-12 Manual. https://www.rand.org/health/surveys/mos/12-item-short-form.html   ... View more

The key thing is when the code EXECUTES.  Normally it executes a block of statements when it sees a RUN statement.  But some statements, like PROC SQL statements, execute immediately.   Try adding ODS TRACE OFF statement it various points and see when it stops listing the generated data. data class1 class2; set sashelp.class(obs=3); run; ods trace on; proc datasets lib=work memtype=data; ods trace off; contents data=work.class1 ; run; quit; Personally I always code the ODS OUTPUT statement before the PROC statement.  That is just much clearer to me than mixing GLOBAL statements into the middle of step.  Just make sure that you have explicitly ended the preceding step. ... View more

You need to execute the ODS OUTPUT statement before the statement that produces the output executes.   PROC DATASETS is an "interactive" procedure, like PROC GLM or PROC SQL.  It can run many different commands before it exits, which is why you need a QUIT statement instead of a RUN statement to mark the end of the step.   In this case the output is generated by the PROC statement itself, so the ODS OUTPUT statement must come before the PROC statement. ... View more

Try this simplified example: options ls=max mprint=1; filename record temp; proc scaproc; record record expandmacros opentimes; run; data x; x=1; run; %global classvars; %let classvars=NAME SEX; %if 0 %then %do; %let classvars=%m_expand_varlist(data=sashelp.classfit,var=_CHARACTER_,out=expand); %end; %if 1 %then %do; %let classvars=%sysfunc(dosubl(%nrstr(proc summary data=x;output out=z;run;))); %end; %put NOTE: &=classvars; proc summary data=x ; output out=y; run; proc scaproc; write; run; data _null_; infile record; input; list; run; Using %SYSFUNC(DOSUBL()) truncates the collection. 21 /* JOBSPLIT: STEP SOURCE FOLLOWS */ 35 22 0 23 data x; x=1; run; 17 24 0 25 %global classvars; 18 26 %let classvars=NAME SEX; 24 27 %if 0 %then %do; 16 28 %let classvars=%m_expand_varlist(data=sashelp.classfit,var=_CHARACTER_,out=expand); 83 29 %end; 5 30 %if 1 %then %do; 16 31 %let classvars=%sysfunc(dosubl(%nrstr(proc summary data=x;output out=z;run;))); 79 32 0 33 /* JOBSPLIT: JOBENDTIME 03JUN2026:16:06:47.17 */ 48 34 /* JOBSPLIT: END */ 19 But calling your macro does not truncate, instead it causes it to write gibberish. 58 /* JOBSPLIT: STEP SOURCE FOLLOWS */ 35 RULE: ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0 59 CHAR ................0 17 ZONE 00000000000000003 NUMR 00000000000000000 60 0 ... 77 /* JOBSPLIT: STEP SOURCE FOLLOWS */ 35 78 CHAR ... ...@...a...p�w�D...Pevo....�.�2............��o�D...u.......��o�D...........��o�D...��o�D....... ZONE 0002100400060007F7A470056760000E1A3000000000000CE6B4700700000008E6B470010000000AD6B4700AD6B470010002 NUMR 000000000001000007F4F00056F0000DF1200000000000007F04F005000000001F04F00100000000FF04F000FF04F0020000 101 ...`...Q...p�w�D...Pevo....�.�2............data x; x=1; 155 ZONE 100600050007F7A470056760000E1A3000000000000667627327333 NUMR 00000001000007F4F00056F0000DF12000000000000414108B08D1B 79 0 80 /* JOBSPLIT: TASKSTARTTIME 03JUN2026:16:12:39.10 */ 51 ...     ... View more

I cannot re-create your issue using SAS 9.4M8.   How was the CHE libref defined? Is it pointing to a directory with SAS datasets? Or something else, like a foreign database?  What happens if you change them both to using the same case for the dataset name (one is using CHE.COHORT and the other has CHE.cohort (lowercase)?  It should NOT matter, but perhaps if your libref CHE is not pointing at a library of SAS datasets then perhaps it does matter.   Also is there anything strange about the name of the variable that seems to go missing?   73 %put &=sysvlong ; SYSVLONG=9.04.01M8P022223 74 filename csv1 temp; 75 filename csv2 temp; 76 77 PROC EXPORT 78 DATA=sashelp.class(where=(age=12) keep=name age sex) 79 DBMS=CSV 80 OUTFILE=csv1 replace 81 ; 82 RUN; NOTE: Unable to open parameter catalog: SASUSER.PARMS.PARMS.SLIST in update mode. Temporary parameter values will be saved to WORK.PARMS.PARMS.SLIST. 83 /********************************************************************** 84 * PRODUCT: SAS 85 * VERSION: 9.4 86 * CREATOR: External File Interface 87 * DATE: 01JUN26 88 * DESC: Generated SAS Datastep Code 89 * TEMPLATE SOURCE: (None Specified.) 90 ***********************************************************************/ 91 data _null_; 92 %let _EFIERR_ = 0; /* set the ERROR detection macro variable */ 93 %let _EFIREC_ = 0; /* clear export record count macro variable */ 94 file CSV1 delimiter=',' DSD DROPOVER ; 95 if _n_ = 1 then /* write column names or labels */ 96 do; 97 put 98 "Name" 99 ',' 100 "Sex" 101 ',' 102 "Age" 103 ; 104 end; 105 set SASHELP.CLASS(where=(age=12) keep=name age sex) end=EFIEOD; 106 format Name $8. ; 107 format Sex $1. ; 108 format Age best12. ; 109 do; 110 EFIOUT + 1; 111 put Name $ @; 112 put Sex $ @; 113 put Age ; 114 ; 115 end; 116 if _ERROR_ then call symputx('_EFIERR_',1); /* set ERROR detection macro variable */ 117 if EFIEOD then call symputx('_EFIREC_',EFIOUT); 118 run; NOTE: The file CSV1 is: Filename=/saswork/SAS_work7E2E0001F819_odaws02-usw2.oda.sas.com/#LN00192, Owner Name=tom.abernathy,Group Name=oda, Access Permission=-rw-r--r--, Last Modified=31May2026:21:51:56 NOTE: 6 records were written to the file CSV1. The minimum record length was 9. The maximum record length was 12. NOTE: There were 5 observations read from the data set SASHELP.CLASS. WHERE age=12; NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.00 seconds 5 records created in CSV1 from SASHELP.CLASS. NOTE: "CSV1" file was successfully created. NOTE: PROCEDURE EXPORT used (Total process time): real time 0.02 seconds cpu time 0.02 seconds 119 120 PROC EXPORT 121 DATA=sashelp.class(keep=name age sex where=(age=12) ) 122 DBMS=CSV 123 OUTFILE=csv2 replace 124 ; 125 RUN; NOTE: Unable to open parameter catalog: SASUSER.PARMS.PARMS.SLIST in update mode. Temporary parameter values will be saved to WORK.PARMS.PARMS.SLIST. 126 /********************************************************************** 127 * PRODUCT: SAS 128 * VERSION: 9.4 129 * CREATOR: External File Interface 130 * DATE: 01JUN26 131 * DESC: Generated SAS Datastep Code 132 * TEMPLATE SOURCE: (None Specified.) 133 ***********************************************************************/ 134 data _null_; 135 %let _EFIERR_ = 0; /* set the ERROR detection macro variable */ 136 %let _EFIREC_ = 0; /* clear export record count macro variable */ 137 file CSV2 delimiter=',' DSD DROPOVER ; 138 if _n_ = 1 then /* write column names or labels */ 139 do; 140 put 141 "Name" 142 ',' 143 "Sex" 144 ',' 145 "Age" 146 ; 147 end; 148 set SASHELP.CLASS(keep=name age sex where=(age=12) ) end=EFIEOD; 149 format Name $8. ; 150 format Sex $1. ; 151 format Age best12. ; 152 do; 153 EFIOUT + 1; 154 put Name $ @; 155 put Sex $ @; 156 put Age ; 157 ; 158 end; 159 if _ERROR_ then call symputx('_EFIERR_',1); /* set ERROR detection macro variable */ 160 if EFIEOD then call symputx('_EFIREC_',EFIOUT); 161 run; NOTE: The file CSV2 is: Filename=/saswork/SAS_work7E2E0001F819_odaws02-usw2.oda.sas.com/#LN00193, Owner Name=tom.abernathy,Group Name=oda, Access Permission=-rw-r--r--, Last Modified=31May2026:21:51:56 NOTE: 6 records were written to the file CSV2. The minimum record length was 9. The maximum record length was 12. NOTE: There were 5 observations read from the data set SASHELP.CLASS. WHERE age=12; NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.00 seconds 5 records created in CSV2 from SASHELP.CLASS. NOTE: "CSV2" file was successfully created. NOTE: PROCEDURE EXPORT used (Total process time): real time 0.02 seconds cpu time 0.03 seconds  Also why did you not get the NOTE about not being able to write to SASUSER library? Are you accidentally running SAS without the RSASUSER option? ... View more

There are a few other wrinkles you have not explored with your examples.   When you create parameters for a macro they are LOCAL macro variables to that macro.   When you reference a macro variable SAS will look for that macro starting with the innermost scope and working its way out to the GLOBAL "scope" (note that GLOBAL and AUTOMATIC macro variables are in the same symbol table and so in the same scope even though SAS prints them with different "scope" values when using %PUT keywords or looking at DICTIONARY.MACROS).      This is even true when you CREATE the macro variable.  So if you write this line inside a macro: %let i=ivalue; And the macro variable I already exists in some outer scope (such as GLOBAL) then the value of that macro variable is modified.  To avoid this use the %LOCAL statement to create a new macro variable in the local scope before assigning it a value.  Or in a DATA step you can skip the %LOCAL statement by using the 'L' modifier when using the CALL SYMPUTX() method to assign the value to a macro variable.  That will force the macro variable into the local symbol table.   An even stranger wrinkle is that SAS will not create the local symbol table for a macro until is it runs a statement that the SAS macro compiler thinks should cause it to need a local symbol table.  This means that any new macros that are created (by using some method that the macro compiler does not notice) will be made in the scope of the calling environment, even if that calling environment is another macro execution and not open code.  Try this example: %macro outer; %let myvar=OUTER ; %put &=sysmacroname BEFORE; %put _local_; %inner; %put &=sysmacroname AFTER; %put _local_; %mend outer; %macro inner; %put &=sysmacroname BEFORE; %put _local_; data _null_; call symput('myvar2','inner'); run; %put &=sysmacroname AFTER; %put _local_; %mend inner; %outer; Where is the macro variable MYVAR2 created? SYSMACRONAME=OUTER BEFORE OUTER MYVAR OUTER SYSMACRONAME=INNER BEFORE NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.00 seconds SYSMACRONAME=INNER AFTER SYSMACRONAME=OUTER AFTER OUTER MYVAR OUTER OUTER MYVAR2 inner Now see what happens if you add a %LET statement to the inner macro.  Try first adding it AFTER the DATA step.  Where is MYVAR2 created? Then try adding it BEFORE the DATA step.  Where is MYVAR2 created? ... View more

If you want to see the values of all current LOCAL macro variables you could query DICTIONARY.MACROS (or SASHELP.VMACRO). 73 proc sql; 74 describe view sashelp.vmacro; NOTE: SQL view SASHELP.VMACRO is defined as: select * from DICTIONARY.MACROS; 75 describe table dictionary.macros; NOTE: SQL table DICTIONARY.MACROS was created like: create table DICTIONARY.MACROS ( scope char(32) label='Macro Scope', name char(32) label='Macro Variable Name', offset num label='Offset into Macro Variable', value char(200) label='Macro Variable Value' ); 76 quit; For an example of using that check out this %symget()  macro which lets you retrieve the value of a macro variable that you could not normally access because it is "hidden" by the existence of another macro variable with the same name in a more local scope. ... View more

Either the data being read has changed and it now has characters that cannot be converted into the encoding being used by the SAS session.   Or you switched to a new SAS session that is using a different setting of the ENCODING system option.   Check the ENCODING system option. Check the encoding of the dataset you are reading from. %put ENCODING=%sysfunc(getoption(encoding)); proc contents data=DATASET; run;   ... View more

With _LOCAL_ you only see the macro variables that exist in the innermost symbol table.   With _USER_ you see the macro variables that live in all of the symbol tables (except those that SAS has deemed to be "automatic").   Consider this example of nested macro calls. %macro outer ; %local mvar; %let mvar=outer; %put %str( ); %put &=sysmacroname _local_; %put _local_; %put &=sysmacroname _user_; %put _user_; %inner; %mend outer; %macro inner; %local mvar; %let mvar=inner; %put %str( ); %put &=sysmacroname _local_; %put _local_; %put &=sysmacroname _user_; %put _user_; %mend inner; %outer; Results SYSMACRONAME=OUTER _local_ OUTER MVAR outer SYSMACRONAME=OUTER _user_ OUTER MVAR outer GLOBAL CLIENTMACHINE ... ... SYSMACRONAME=INNER _local_ INNER MVAR inner SYSMACRONAME=INNER _user_ INNER MVAR inner OUTER MVAR outer GLOBAL CLIENTMACHINE ... ... You can see that the call to %PUT _USER_ inside of the macro %INNER shows the local macro variables for both the %INNER and %OUTER macros. ... View more

I think you are looking for the  _LOCAL_ keyword in the %PUT statement.  That will exclude the GLOBAL (including the "automatic"ly global) macro variables.      I agree that the name of the macro is confusing.     SCOPE is already a little overloaded with meanings:   It has a general meaning in computer programming: Scope defines where variables can be accessed or modified in your program. It determines the visibility and lifetime of variables - in other words, which parts of your program can "see" and use a particular variable.  https://www.w3schools.com/programming/prog_scope.php It is also used as the name of the variable in SASHELP.VMACRO dictionary view that let's you examine the values of macro variable as a dataset. It would be better if they used something like MYMACRO as the macro's name instead. ... View more

I am not sure why you have switched from making a powerpoint presentation to making an Excel workbook.   But the ERROR message. 92 ods excel close; ERROR: Physical file does not exist, C:\Users\learnsas-16391\&\pressure.xlsx. Lines up perfectly with what you asked it to do. ods excel file="&/pressure.xlsx" style=analysis; The error message is saying it could not find a directory named & inside the current working directory of C:\Users\learnsas-16391 on the Windows machine where SAS is running.   But why do you have that &/ in the value of the filename you passed to the FILE= option of the ODS EXCEL statement?   If you wanted to create the file: C:\Users\learnsas-16391\pressure.xlsx Then use one of these methods: * Relative filename ; ods excel file="pressure.xlsx" style=analysis; * Absolute filename ; ods excel file="C:\Users\learnsas-16391\pressure.xlsx" style=analysis; * Absolute filename created by using a macro variable reference; %let outpath=C:\Users\learnsas-16391\ ; ods excel file="&outpath.pressure.xlsx" style=analysis; You can use / in the filename and SAS will know to convert them into \ when it is running on Windows, as your example error message indicates.  So that last example could be: * Absolute filename created by using a macro variable reference; %let outpath=C:\Users\learnsas-16391; ods excel file="&outpath./pressure.xlsx" style=analysis;   ... View more