Agree with the advice from Kurt and Paige.  It's really important to separate SAS programming questions (e.g. how do I output a PDF that has a table and a graph in it) from macro programming questions (how do I automate generation of code to make multiple PDF reports...).   So first you write the SAS code (no macros!) to make two reports.  And in doing so, you may hit challenges, and you can post questions about the SAS programming challenges.   Then after you have working SAS code, you can work on writing a macro that will generate the working SAS code.  Then when you hit macro language challenges, you can post questions about the macro language.  And in those questions, you can show the working SAS code you are trying to generate, and also show the non-working macro.  That will make it easier for people to understand the intent of the macro, and help with resolving macro language issues.   Also, if you're still learning the SAS language, it may be too soon for you to try learning the macro language.  The macro language is a completely separate language.  I often recommend to beginners that they program in SAS for a year or two, until the point that they are really confident that they understand the SAS language, and also understand the purpose of the macro language, before they start learning to write macros. ... View more

Without seeing the code  that defines the macro CORE, this is just a wild guess.   Assuming you have an input dataset named Exam_long.sas7bdat in the directory ~//…/Example_Analysis/   You could change the line: * Input SAS file member name; %LET CORE="~//…/EXAM_long"; To: * Input SAS file member name; %LET CORE=EXAM_long; But that's just a wild guess.  Personally, I think it's a bit dangerous for programmers to be asked to use macros, without being given an explanation of how the macro works, at least documenting the inputs and outputs.  I would recommend you review the macro definition, perhaps with the original macro programmer or another colleague, to understand how it works. ... View more

As mentioned, transposing to a long format will make this easier.   I would transpose, and also change the missing value codes (-7,-8,-9) into special missing values, e.g.:   Data have; input CustID RevRatio1-RevRatio12; cards; 1 0.9 0.8 0.8 0.7 0.9 0.9 0.7 0.6 0.9 0.9 0.7 0.6 2 0.6 0.1 0.2 0.3 0.2 0.4 0.5 1.1 0.9 0.7 0.8 0.9 3 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 4 -9 0.2 0.1 0.4 0.5 -9 -8 0.1 0.2 0.3 0.4 0.1 ; Run; data vert (keep=CustID Seq RevRatio); set have ; array Ratios {*} RevRatio1-RevRatio12 ; do Seq=1 to dim(Ratios) ; RevRatio=Ratios{Seq} ; *recode negative missing codes to special missing values ; if RevRatio= -9 then RevRatio=.A ; if RevRatio= -8 then RevRatio=.B ; if RevRatio= -7 then RevRatio=.C ; if RevRatio= -6 then RevRatio=.D ; output ; end ; run ; In that structure, you can use use the LAG function to see the prior month's (?) value.  And then calculate pct change, etc.  Something like: data want ; set vert ; _lagRatio=lag(RevRatio) ; *This calculation seems backwards for pct change ; *I would expect (RevRatio-_lagRatio)/_lagRatio ; if seq>1 then do ; if (RevRatio ne 0) and (n(_lagRatio,RevRatio)=2) then PCT_change=(_lagRatio-RevRatio)/RevRatio ; *I am not convinced below logic is correct ; if (PCT_change>.05 and _lagRatio>.5) or (_lagRatio>1 and RevRatio<1 ) /*This will include missing values for RevRatio! */ or (RevRatio ne .A and _lagRatio=.A) or (_lagRatio > .5 and RevRatio IN (0,.A,.B)) then Ind=1 ; else Ind=0 ; end ; run ; *Check the logic ; proc freq data=want ; tables RevRatio*_lagRatio*PCT_change*Ind/missing list ; run ; When you have repeated / longitudinal data strung out in wide format, the macro language can help you generate lots of code.  Using the array statement can make  it easer to reference lots of variables with pointers / indexes.  Transposing to a vertical structure lets you write less code. ... View more

You might want to look into the (3rd party) security plug-ins from Metacoda.  https://www.metacoda.com/en/    They make it super easy to answer questions like "What can this person/group see" and "Who can see this data" etc. ... View more

Agree with others, that code is usually simpler and more readable if you use SAS date values.     In this case, if you pass in a SAS date for start and end, then you can increment by month within the loop using INTNX.   Note I had to add 1 to &end, because the macro compiler won't let you use %BY 0 for fear of an infinite loop.  This could also be done as a %DO %WHILE or %DO %UNTIL, if that hack is unappealing to you.   %macro foo(start,end) ; %local date ; %do date=%sysevalf(&start) %to %sysevalf(&end+1); %*Add a day to end because do-loop will increment by 1; %put %sysfunc(putn(&date,yymmn6)) ; %let date=%sysfunc(intnx(month,&date,1)) ; %end ; %mend foo ; %foo("01Jun2023"d,"01Mar2024"d) ... View more

Looks buggish to me.  You might want to submit to tech support.   That sometimes happens if you have too many groups, but in that case you get a warning in the log.  That doesn't seem to be the problem here.   If you comment out the REG plot, you get don't get the connected zigzag.   proc sgplot data=long noautolegend; series Y = Y X = t / group = p lineattrs=(color=ligr pattern=1); * reg Y = Y X = t / group = trt nomarkers; run; If you leave the reg plot but change it to group by P, you don't get the zigzag: proc sgplot data=long noautolegend; series Y = Y X = t / group = p lineattrs=(color=ligr pattern=1); reg Y = Y X = t / group = p nomarkers; run; If you replace the reg plot with a scatter plot, you don't get the zigzag proc sgplot data=long noautolegend; series Y = Y X = t / group = p lineattrs=(color=ligr pattern=1); scatter Y = Y X = t /group=trt ; run; So seems like there is an odd interaction (bug-ish) where having the REG plot overlaid and using a different GROUP variable is causing a problem for the SERIES plot grouping. ... View more

Thanks @Tom for your further thoughts.  I'm definitely a fan of using a hierarchy of autocall macro libraries.  I also search the local first, so I search project macros, then corporate macros, then SAS-provided macros.  I think it's good to allow the over-rides.  For some projects my project macro directory may be empty.  But if for some reason I need to tweak a corporate macro, I can put it in the project directory and update it.   I hadn't thought about a system where you need to "register" macros before they are used, rather than use an actual autocall library.  That's an interesting idea. For my first few years of using macros, I used a %INCLUDE approach for my personal macro library, but it didn't have a dynamic feature to specify a date/version.   In fact that reminds that @KevinViel maybe consider storing the autocall macros in a SAS package https://github.com/yabwon/SAS_PACKAGES ? That would also give users an easy path to "install" on demand, and the ability to specify the specific version to be used. I'm sure @yabwon would be happy to talk you through that approach. ... View more

I don't think it's quite as simple as saying "use version control." Would be interested to hear more about how people implement this.   So take the scenario where a company has a shared library of corporate autocall macros, and then there are multiple projects being worked on by different developers.   I'm curious @AhmedAl_Attar  and @Tom , if you can say more about the setup you would propose.   Typically a shared macro library would be stored in a location accessible to all programmers. So in some directory you have /CorpMacros, which could have .sas files (or compiled macros I guess), and then users would point their code to that directory (or it would be defined in a shared config file or whatever).  I think in this scenario, individual programmers would never need to check out macro code from a repo.  An admin would be responsible for maintaining the code in /CorpMacros.  In that setting, it's not a trivial step to roll back a macro to a prior version, because doing so would roll back the macro for every programmer in the company.   I suppose a different approach would be to keep your CorpMacros in git or whatever version control. And each project could have a local (the project) directory for storing its own collection of the CorpMacros.  Meaning for each project, the programmer(s) for that project would be responsible for deciding when they want download macros from the version control storage.  With that setup, each project could decide when to download an updated version of the a corporate macro.  So each project would basically have its own independent copy of the corp macro library.  Project A could be running %FOO v1, while Project B is running FOO v2.   I guess with the second approach, it's more work for the programmers working on the projects.  But it does give them control as to which version of a corp macro is being used for their project. And makes it easier for Project B to revert to an older version of %FOO any time they want.  In a sense this approach doesn't really have a corp macro library which is accessible to SAS.  Instead the corp macro library is stored only in version control.  And each project is responsible for maintaining a project macro library by pulling files from repository.  One down side of approach #2 is that if a developer makes a critical bug fix to  %foo, they then need to tell every project to make sure they pull down the latest version of the macro.   While I'm  fan of corporate libraries, and I was responsible for maintaining one for years at a prior employer,  I think it's a tricky task to administer properly.  And as a user of corporate macros, it always felt a bit weird to know that a macro I call on  Tuesday might do something different than it did on Monday, if the corp macro czar had updated it for some reason.  For some critical projects, I would take a snapshot of the corp macro library and store it as a project macro library, just so that I would have control over it. ... View more

Hi Kevin.  If you don't want the log message every time you call the macro, you can add a %PUT statement to note the version number before the %macro statement.  So it can look like:   %put NOTE: Compiling %nrstr(%%)dummy (v 1.0) from autocall library ; %macro dummy(); %* <remainder of macro code> ; %mend; The first time the macro %dummy is called in a session, SAS essentially %includes dummy.sas, so the %PUT statement will execute.     Sometimes I will add the path to the .sas file to the note as well.   I think something like that helps to get the version number in the log.  Then using git or whatever version control on the actual .sas files.   ... View more

I would back up and think about non-macro approaches to implementing this sort of range check.   The idea of having a dataset range checks is a good one.  When you have date values in a dataset, you want to store them is date values (numeric variables), not character.  So your data could be like: DATA HAVE; INPUT MEMBERID : $20. DOB : MMDDYY10.; Format DOB MMDDYY10.; CARDS; 1111 1/12/2001 2222 2/11/2003 3333 3/11/2003 4444 1/13/2000 ;run; DATA RANGE_CHECK; INPUT Check_Number Low_DT : mmddyy10. High_DT : mmddyy10.; format Low_DT High_Dt mmddyy10. ; CARDS; 1 3/1/2000 5/1/2001 2 1/2/2002 12/2/2003 ;run; Note I removed the macro variables from the CARDS data.  That won't work. If you want to make this data dynamic, happy to discuss alternative approaches.  I also make Low_DT and High_DT numeric date variables, rather than character.   Once you have that data, there are lots of different way to implement the range check.  One would be to use PROC SQL.  Below will join every record in your data against every check, and output the records where DOB is in the range.  You'll get a note in your log that SAS is performing a Cartesian product.  In this case, four records from HAVE * 2 records in RANGE_CHECK would result in 8 records, which are then filtered.  If you have big data, the Cartesian product may be slow, but it's one way you could approach the problem.   proc sql ; create table want as select b.check_number,a.memberid,a.dob from have as a ,range_check as b where b.low_dt<=a.dob<=b.high_dt ; quit ;   If you look on lexjansen.com (an archive of SAS papers written by users) and search for "range check", you'll find lots of different approaches to implementing checks like this.   ... View more

The tech support link from @RobH looks like it should help.   But I checked my Win10 PC, and the registry key in the paper looks like: When I double click a .sas file, it opens  in Display Manager (PC SAS).  9.4M7   ... View more

I'm wary of OneDrive as well.  The idea of magically syncing to the cloud and only storing locally what is needed sounds nice in theory, but I find it scary.  Can I really trust that OneDrive is smart enough to give me the current file every time I read it, rather than let me read an old cached version? I'm viewing my OneDrive use case for this Excel file as a test case... The short-term project I did this for turned into a medium-term project, so there is ongoing work to get the data out of Excel and into a database, which will of course make everything work better.   I can't imagine storing a big SAS dataset in one drive and having it download from the cloud in the background when I try to read it.   We also had a "store everything in OneDrive" idea at work.  And they moved our "My Documents" folders to One Drive.  But I think many people are ignoring it.  Might make sense for Word docs and little stuff where there is need for collaboration, but I don't need it for code or data.  And don't really want it in the background, messing with backups etc. ... View more