Hi:
If this is code that you have inherited and if the code was/is working the way you want and if you need to modify the way the macro code or SAS process is operating now, then I recommend that you do not change the current process, but instead, leave it intact.
Then, I recommend that you start to analyze the existing process by tracing -- all the way back to the beginning of the code-- what all the inputs and outputs to your macro program are. For example, this code snippet shows 3 different files -- all WORK files. There must be some intermediate processing that creates at least 2 of these 3 files -- where do WORK.KAIMPORT and WORK.SCH come from? How are they created and what do they represent. It is possible that one of both of them contains all the counties that you want.
Without understanding how and where WORK.KAIMPORT and WORK.SCH get created, it is impossible to tell you how to proceed. There -are- valid reasons for using an UPDATE statement -- generally, UPDATE is used in a "master/transaction" scenario, where one file contains the "master" dataset and the other file contains "transactions" or "updates" (in old batch processing lingo) which should be applied to the master file based on some common variable. To learn more about the UPDATE statement, consult the documentation. You want the UPDATE statement (NOT the SAS Component Language UPDATE function).
In your code snippet, WORK.KAIMPORT is in the syntax position of the MASTER dataset and WORK.SCH is in the syntax position of the TRANSACTION dataset. Based on this information, then either WORK.KAIMPORT or the dataset from which WORK.KAIMPORT is derived might contain the information that you want/need.
(The only thing that the %EVAL is doing was making sure that &CONUM was treated as a number in the subsetting IF. You should get the same results whether the %EVAL is there or not. I suspect that cocode is a character code and that somebody coded multiplying it by 1 to create the CO variable as a number -- probably because they wanted or needed a numeric version of the country code.)
If you have both WORK.KAIMPORT and WORK.SCH in place (undeleted) after the code runs, you might try this and see whether the resulting file contains what you want:
[pre]
data what_is_ka;
length co 4;
set work.kaimport;
co=cocode*1;
run;
proc freq data=what_is_ka;
tables schcode co cocode;
run;
proc print data=what_is_ka;
run;
[/pre]
Or, if you only get the (in=a) records, which are coming from WORK.KAIMPORT, you might first try a PROC PRINT on WORK.KAIMPORT to see whether it has all the counties you need. The other thing to do is to trace farther back in the program and try to see where the FIRST place is that &CONUM gets set and where the FIRST place is that WORK.KAIMPORT gets created.
You might also consider contacting Tech Support for help. They can look at ALL of your code and ALL of your data and help you figure out the best way to proceed to code for your new requirements. Learning about SAS macro variables and macro programming can seem like a daunting task on top of learning how SAS operates. But it is do-able. The Macro documentation is very good and there are a number of user group papers that can give you a broad overview of macro processing concepts.
Again, if this is legacy code that you have from someone else, and if it's working as desired, then I advise you not to change -THIS- program until you really understand what it's doing -- master/transaction updates were/are used to mimic mainframe type batch transaction processing -- so I would advise against recoding that program until you really understand what the input files and output files all represent and how they're transformed at the various stages of your program.
cynthia
