Hi,
I suspect this is a CALL EXECUTE timing problem.
When CALL EXECUTE executes code that uses data to generate macro variables, the timing is tricky. Your macro:
%macro LoopLibraries(HDFSLIBRARY);
LIBNAME &HDFSLIBRARY. SASHDAT PATH="/&HDFSLIBRARY." SERVER="svfl-app-p021.ndis.be" INSTALL="/opt/sas/int/TKGrid" ;
proc contents data=&HDFSLIBRARY.._all_ out=datasets noprint;
run;
proc sort nodupkey data=datasets; by libname memname; run;
data looplibraries;
set datasets;
lasrlib = strip(substr(libname,1,length(libname)-1)) || "L";
if memname = "TABEL_A_TEST";
call execute('%ReloadTable('||strip(libname)||','||strip(memname)||','||strip(lasrlib)||');');
run;
%mend;
Uses CALL EXECUTE to invoke %RELOADTABLE. It will immediately execute %RELOADTABLE and generate a bunch of SAS code and write it to the input stack. But all of that code is written to the input stack before
proc sql ;
select count(*) into :to_be_loaded from tablelist
has executed, so &to_be_loaded is not what you expect.
To avoid this problem, you can add %NRSTR() to your call execute:
call execute('%nrstr(%ReloadTable('||strip(libname)||','||strip(memname)||','||strip(lasrlib)||'))');
This will allow call execute to place the macro call on the input stack, rather than execute the macro.
It allows the timing to work out, and also makes the log cleaner, because you see the macro call generated by call execute.
For more explanation of this CALL EXECUTE timing issue, see e.g. https://blogs.sas.com/content/sgf/2017/08/02/call-execute-for-sas-data-driven-programming/
... View more
