Take advantage of the fact that macro language performs integer arithmatic, dropping any remainders.  Try:   %if &v = &v / 5 * 5 %then %do; ... View more

Is there any reason you need to use DEMAND_LABEL in your program?  Can't you just use the first character in ID_DEMANDE instead?  This might get you most of the way there: proc freq data=have; tables id_appel * id_demande / noprint out=counts (keep=id_appel id_demande count); format id_demande $1.; run; You still need to reformat the counts (including adding zeros where appropriate ... see if the SPARSE option would do that for you), but wouldn't those counts be correct? ... View more

It depends on what you mean when you say you have two or more variables.  So give an example.  Certainly the BY statement supports multiple variables, but the outcome might not be what you have in mind. ... View more

A few comments ...   How do you measure the frequency?  We don't see that in your program.  Remember, PROC FREQ will automatically remove observations where one of your variables is missing.   Do you really need a new variable, or do you just need to know more about the original variables?  Here's a program that will help you learn about the original variables without creating a new variable: proc freq data=project; tables v2 * v5 / missing list; tables v7 * v8 / missing list; run; See whether that does what you need, or whether you really need to create variables. ... View more

Here's a variation that simplifies the logic, eliminating the complications.   %macro apaga; %do i=1 %to 9; data _null_; if done then call execute("proc delete data=x&i; run;"); stop; set x&i end=done; run; %end; %mend; %apaga By switching to PROC DELETE, the code also can be easier to use if your source data sets are in more than one library. ... View more

First thing to check for:  does your db_policies_total data set already contain a percentages variable before the merge.  If that's the problem, you can get rid of it using: date db_pol; merge db_polices_total (in=a drop=percentages) quota_share (in=b); by catena; if a; Of course, I don't know  your variable names.  You would have to use the proper name that exists in your data. ... View more

Are you able to post the actual log (not just the notes on the log) from the test you ran?     I understand you may not be able to do that because of confidentiality reasons, but post what you can. ... View more

This is a proc sort.    I didn't know the names of the 13 variables in your BY statement, so you would have to replace the BY statement with the actual variables you are using.   Rather than typing the name of your incoming data set, I used a made-up name _16_variables.  I expect you would use your actual data set name.   I used out= to avoid replacing the original data set.  If you replace the original data set, the second PROC SORT would be skipped since SAS detects that the data set is already in sorted order.   So the idea is to run PROC SORT twice on the same data set, using out= to name the sorted data set.  One PROC SORT uses TAGSORT and one doesn't.     If that's not clear, please ask again. ... View more

Wow!  Thank you for testing it.   That is so counter-intuitive (at least to me), that I wanted to confirm.  Was the test that you performed along these lines?   proc sort data=_16_variables out=test1; by list of _13_ variables; run; proc sort data=_16_variables out=test2 tagsort; by list of _13_ variables; run; ... View more

Get rid of TAGSORT! You only have 16 variables in the data set, and you need 13 of those as BY variables. So TAGSORT saves reading 3 variables but adds the need to pass through the data twice. As long as the sorting actually completes, removing TAGSORT should speed things up. ... View more

For most of this, macros are not really needed.  This is a program that automatically adapts to the variables you have, except for determining names for the new variables.  That part you have to add yourself.   data want; do until (last.id); update have (obs=0) have; by id; end; *** The next 3 lines are being hard coded. If you are clever, it can be automated; late_bp = bp; late_weight = weight; late_bc = bc; do until (last.id); set have; by id; output; call missing (of late_:); end; run; The code is untested, so post again if something isn't working for you. ... View more

Yes.   Do you have access to documentation about PROC SORT? ... View more

Your program contains this line: %put &sex; You will need to show us the results of that %PUT statement, from the log. ... View more

DATA steps contain a tool to make this easy.  You don't need CALL SYMPUT at all.  You don't need a macro definition.  To execute one set of code or another after your DATA step ends, here is the way to do it: data _null_; set stats; if PROB > 0.25 then call execute( 'proc glm data=stability; model RP=time; run;'); else call execute( 'proc glm data=stability; class batch; model RP=batch time batch*time; run;'); run; If STATS contains multiple observations, you may need to add to the logic to make sure you execute this logic just once. ... View more

If you are certain that the code is trying to test for a null value in &TYPE, there are a few ways to do it.  An entire paper has been written on the subject.  But the chosen method is not a valid way: %if &type. > ' ' %then AND p.type_c = &type; This method is not correct, because macro language treats quotes as text in that statement.  So the test is whether &type is greater than a quote (or greater than two quotes).  The method I usually choose (and reasonable people can select alternatives) is: %if %length(&type.) > 0 %then AND p.type_c = &type; ... View more