Macro debugging: autocall issues

[A_Kh]

Dear Community Experts, 

I'm using autocall (options MAUTOSOURCE ) in my program.
The way called macros behave is strange: sometimes gets resolved, sometimes don't. It happens mostly when Batch submitted or even submitted  while the program is open. Warning message is generated, following with Error messages (this is caused by unresolved macros). To my surprise, it's not always the case. Sometimes program works without issue. 
Whenever I have an issue, I have to open macro directory and submit the unresolved macro from there, then run my main program in order to clear error and warning messages. Tee same happens for macros containing proc formats, formats are not loaded to the main program...
My system uses SAS 9.4 (32 bytes) Windowing Environment.
All SAS Programs, input datasets and macro directories located in Cloud (OneDrive).
I assume the connection to the Cloud is affecting macros to compile on time. 

Is there anybody who had the same issue and found a resolution? 

[SASKiwi]

Try copying all programs to your local drive and run some tests using this. If your AUTOCALL macros work reliably on a local drive it is safe to conclude that OneDrive is the cause of your problems. 

[ballardw]

Without actual details of the particular error messages it is pretty hard.

Do you have more than one person editing the macro files so that things change unexpectedly?

Have you compared the differences between a batch file SAS configuration and an interactive session? There are some and if you don't have things pointing to the same folders in all the configuration then you could expect such.

If your autosource isn't working reliably I might suggest placing  a %include in your Autoexec that calls all of the macro files so that they are forced to compile.

With that said, I have suspect intermittent behavior with an occasion data set seeming not to update as expected on One drive. I have also had One-Drive lose 100+ files in a folder. My IT guy said that One Drive may have issues with folders with many small files. So if your autocall library has "too many", and I have no idea what the actual number my be, files that might be part of the issue.

Any of your cloud storage is going to rely on network service and if the service is delayed because of network limitations or the app gets busy doing something like "searching for updates" that might be an issue as well.

[A_Kh]

Thank you @ballardw ,

%include is actually helpful. I had tried that option as well, it helped with compilation for all, except the one that creates formats for the main program. 
To answer your questions, I'm the only user for now to use/update those macros. A cloud folder contains around 30 macro programs (each containing 5-15 macros). 

I did not understand "comparing difference between a batch file SAS configuration and an interactive session".  Is there a different configuration for a batch mode?

I'll save error/warning message screens next time and i'll add to our chat in here. 

[ballardw]

---

@A_Kh wrote:

Thank you @ballardw ,

%include is actually helpful. I had tried that option as well, it helped with compilation for all, except the one that creates formats for the main program. 
To answer your questions, I'm the only user for now to use/update those macros. A cloud folder contains around 30 macro programs (each containing 5-15 macros). 

I did not understand "comparing difference between a batch file SAS configuration and an interactive session".  Is there a different configuration for a batch mode?

I'll save error/warning message screens next time and i'll add to our chat in here. 

---

If you want to use autocall you cannot have multiple macros defined in a file. For autocall each macro must be in a separate .SAS file and the name must match that of the macro.

I'm a little concerned about your comment about format code. Generally that is relatively static. If the formats do not change every session you would be better off placing the formats into a permanent library, the Library= option in Proc Format, and then have your autoexec add that library to the FMTSEARCH path.

There are a few default differences in how SAS starts between batch and interactive unless you have gone to some effort to control them. Run Proc Options in both environments and capture the log to compare the results.

[Quentin]

---

@ballardw wrote:

---

---

If you want to use autocall you cannot have multiple macros defined in a file. For autocall each macro must be in a separate .SAS file and the name must match that of the macro.

As a side note, the first part of the statement is not correct.

You can actually put a file mymac.sas in your autocall directory that has (untested):

data want;
  set sashelp.class;
run;

%macro mymac();
  %put hi mom;
  %mymachelper();
%mend mymac;

%macro mymachelper();
  %put hi dad;
%mend mymachelper;

When you call %mymac, the data step will be run, and both macros will be compiled.  I think the autocall feature is basically doing an %include.

Not suggesting this would be a good practice.  But I have seen people use it when they wanted to have a helper macro that was, in a sense, tightly coupled to the main macro.

[SASKiwi]

That's interesting. I've always assumed the restrictions as listed in the documentation and as repeated by @ballardw apply. Agreed it isn't good practice though.

[ballardw]

---

@SASKiwi wrote:

That's interesting. I've always assumed the restrictions as listed in the documentation and as repeated by @ballardw apply. Agreed it isn't good practice though.

---

I've always figured that if the documentation says it that even if something -sometimes- works that isn't exactly compliant that the exception that has issues may be a problem to chase down. As in the OP's description of intermittent compiling.

[Patrick]

---

@SASKiwi wrote:

That's interesting. I've always assumed the restrictions as listed in the documentation and as repeated by @ballardw apply. Agreed it isn't good practice though.

---

If the macro is not already compiled then SAS does nothing else than search through folders based on what's define in SASAUTOS until it finds a file <macro name>.sas

If <macro name>.sas is found then it gets executed (compiled) and then the macro gets executed. If you have other macro definitions in <macro name>.sas then they get all compiled as well.

I'm using this (rarely) for specialized helper macros used by the main macro where I want to keep the code together in a single .sas file for maintenance reasons.  ...and always with a lot of comment in the .sas file what this is doing and why it's done this way.

[Quentin]

This hack can also be used as a custom version of MCOMPILENOTE.  So in  mymacro.sas you have:

%put Compiling macro MyMacro version 1.5;

%macro mymacro;
  ...
%mend;

You'll get that note in the log when it is compiled.  You can have version number, a path to the .sas file, author info, etc.  Some people like to write macros with a help parameter that writes instructions to the log.  This approach could be used to write instructions to the log when the macro is compiled.  Also could be used for people who want to track how often different autocall macros are 'used', since one definition of used could be the number of sessions where the macro was compiled.

I think I've got one or two macros where I did the multiple macros in one file thing.  While it felt a little sleazy, it never caused a problem.  Other than of course a month later when I read through the main macro and see a reference to %helper, I usually waste 5 minutes trying to find the helper.sas until I remember that it's defined in the same file.  So there's that. : )

[Tom]

Yes.  SAS even publishes some of those monsters.

The basic process is that if the macro you are calling is not yet defined SAS looks to see if there is a file with that name. In then executes the file. And then finally calls the macro.

So your code would work.

The first time you call the macro it runs the data step, defines %MYMAC(), defines (or re-defines) %MYMACHELPER() and then runs %MYMAC().

The next time you call it it just runs the macro. So the data step does not run again and %MYMACHELPER() is not re-defined.  So if you did something like this:

%mymac();

%macro mymachelper;
  %put hi mom;
%mend;

%mymac();

The second call will say hi mom instead of hi dad.