08-18-2011 09:43 AM
I need to scan program code looking for certain variables that are kept in the set statement.
I need to qc some code. The program reads in some datasets using the set statement. Only some of the variables in each dataset are kept using the keep= statement for further processing in the code.
I have to make sure that each variable in the keep= statements is actually used in the code further down otherwise to remove the variable from the keep= statement.
Is there any way I could automate this process?
set inds1(keep= customer product cost)
inds2(keep= customer age address);
so I would like to run code which will check to see that all the variables are used in the sas statements below)
any variables that are not used to list.
Thanks in advance
08-18-2011 09:56 AM
One way would be to replace your RUN statements with RUN CANCEL statements, and then capture and parse the log looking for: the strings: "WARNING: The variable" and "in the DROP, KEEP, or RENAME list has never been referenced"
08-18-2011 10:33 AM
Tried this but think it doesn't really work for my purpose. I think I will only get the message "...var ....has never been referenced" when in a statement, but not in a dataset option ie Keep=
Wrote some code which may make it easier to see:
set test1(keep=a b c);
*--- var a is used - OK;
*--- var b is used - OK;
*--- but var c is not used so there is no need to read it in.;
*--- this is what i need to capture ie c;
Cheers about the run cancel; statement..didn;t know about this.
08-18-2011 10:51 AM
There are a number of occassions when one will still want to keep variables that are read in, but which are never addressed in one's code. I would feel safer if the code also included a keep option in the file identified in the data statement. Then, you would only have to parse the code for fields that are in the set options's keep statement, but neither in the data statement's keep option and never used in the code.
i.e., if you can narrow down the variables, the run cancel concept could be used to test the code by removing those variables, one by one, from the set statement's keep option. Would that accomplish what you are trying to do?
08-18-2011 11:04 AM
The code I am working with does have a keep= statement in the data statement. It keeps vars which have been read in the set statement but are not processed but are required.
Was hoping to see if there was a way I could scan the program file with specific words..ie with the the vars in the keep= statement. Thought maybe a macro could be used whereby i copy and paste the keep= vars into it and sas scans the code to see if it encounters them. If I get a count of >1 then I know they are referenced elsewhere, either in the data statement or in the code after the set statement. If they are only referenced once ie i the actual set statement I just copied them from then would think I can safely say they are not needed.
Manually removing one var at a time and run cancel; is not a viable option at this moment.
08-18-2011 09:06 PM
I don't have a packaged program for you, but I think that the following contains all or most of the nuggets that you might need. The code would have to be modified to match the layout of your own code, and your coding practices would have to be sufficiently uniform for any parsing of this type to work. Hopefully, the following will at least provide you with a start:
input a b c d;
1 2 3 4
5 6 7 8
/* program saved as c:\art\testcode.sas */
/*data test (keep=x y);*/
/* set example (keep=a b c);*/
filename partcode "c:\art\partcode.sas";
length word $32 datakeep $50 setkeep $50;
infile "c:\art\testcode.sas" lrecl=300 end=eof;
if index(upcase(_infile_),"DATA ") then do;
else if index(upcase(_infile_),"SET ") then do;
else if index(upcase(_infile_),"RUN;") then do;
length names $300 name $32 type $3 length 3;
do i=1 to 999 until(name=' ');
if not (substr(name,1,1) eq "_" or
upcase(name) in ('WORD','DATAKEEP','SETKEEP','EOF',
else put _infile_;
08-19-2011 02:38 AM
Many many thanks for this and the work you put in.
Just in the office now so not had time to look at it. Will hopefully get back to you today or monday to let you now it goes.
08-23-2011 01:38 AM
I've not been able to go through this code yet. Pretty busy at the new job for which this macro was for. Not too sure about some of the code and logic so will have to take a bit of time to go through it..when i can find the time.
Will get back soon