these statements are not executed in the lines you show here.
These lines prepare strings which would execute validly in other contexts when the code refers to &shift_today or &month_criteria
The first of these statements will derive a date (number of days since 1960) for the first of the month before the datetime when that syntax is finally executed.
The second is an attempt (which might work) to derive the date string YYYYMM for the month before the month when that &month_criteria is resolved/executed.
it could be done so much more reliably, and understandably (imho)
Normally a macro variable &something is a convenient way of re-using a constant.
The risk with using &month_criteria more than once in a sas program occurs when the sas program starts just before midnight at the end of a month - and there is a chance (=risk) that a subsequent use of &month_criteria in the same sas program would execute after that midnight - and so return a different "month". That is not normally what one would want.
Rather than store syntax in &month_criteria, store the value, with
%let month_criteria = %sysfunc( intnx( month, "&sysdate"d, -1), yymmN6 ) ;
where &sysdate is the built-in string for the start date of the SAS system which runs the program.
Then all references to &month_criteria will result in the same string.
and if you are invoking my code in a server that runs for many days- and so may have historic start date, replace "&sysdate"d with %sysfunc(date())
Of course if the purpose of the statement
%let month_criteria=(year(&shift_today)*100+month(&shift_today));
is to confuse, or to prepare an explanation
it may achieve its purpose.
but I don't know what the author had in mind
peterC
