SASEG8.3 fail to use self-built macro program stored in WinServer.

[YUXI]

I am a user of SASEG8.4 which linked to a WinServer, and I have a SAS MACRO FILE stored in my WinServer.

When I try to use macros in this FILE,

• In SAS 9.4 (WinServer): I can get correct output.
• In SASEG8.4 (my own PC): I cannot get output dataset, with "WARNING: The argument to macro function %SYSGET is not defined as a system variable."

It seems like I cannot call complex MACROs from WinServer?

How to fix this trouble? Hope anyone could help:)

[SASKiwi]

The %SYSGET macro reads OS environment variables. I suspect this environment variable is not defined on the computer your EG SAS session is running on. Does your EG connect to a remote SAS server? Also please post the macro code so we can see what it is doing.  

[YUXI]

Yeah, my EG has already connected with SAS WinServer, and I can use it normally.

But, Actually, I am not the author of this MACRO FILE, so i cannot get the source code. The only thing I know is that, when this MACRO FILE is stored in everyone's own PC (rather than Server), macros in this FILE can be normally used in personal SAS 9.4 without problem.

By the way, I have tested like this: created a very "simple" MACRO stored in WinServer, and then called it successfully in my SASEG.

The code below is my test macro:
----------------------------------------
libname test "D:\test_macro";
options mstored sasmstore=test;
%macro text_output()/store source;
%put "Welcome to use SAS MACRO!";
%mend;
-------------------------------------------------

So, i am not sure if this MACRO FILE can only be used in SAS9.4, rather than stored in Server and then used in SASEG.

[Tom]

What do you mean by a "macro file"?  Are you talking about a SAS program file that contains the SAS code to define the macro?  Or are you talking about a SAS catalog object of an already compiled macro.

I am also not sure what you mean by saying "SAS WinServer".  Do you have a computer running Windows Server?  Are you connecting to the server and running the Windows application Enterprise Guide remotely on that Windows Server instead of running it on your local copy of Windows?  Or do you mean that your Enterprise Guide session (whereever it is running) is connection to a copy of SAS that is running on a WIndows Server instead of connecting to a copy of SAS that is running on the same machine as Enterprise Guide.

The %SYSGET() function in SAS is for retrieving operating system environment variables from the computer that is running the SAS code (not the computer where Enterprise Guide is running).  So if the macro was working when call from SAS running on a users local Windows machine then their machine probably had that environment variable defined.  If then fails when run on the Windows Server machine then that environment variable must to exist on that machine (or perhaps it exists but the value is not appropriate for what the macro is trying to do with it).

[Tom]

That code does nothing other than generated an entry in a catalog that contains the compiled version of the macro.

Are you saying that trying to run that code does not work?  Does the path mentioned in the LIBNAME statement actual exist on the new machine?

Or are you saying if when you actually do try to run that macro it does not work?

Catalog files are normally not portable across SAS versions (meaning a change to any of the SAS release, the operating system, 32bit vs 64bit, etc.).  So if you want to use a stored compiled macro on a version of SAS running on Windows Server you probably need to have created the stored compiled macro on that machine and not be trying to access a verison compiled on a different version of SAS.

That it why I find it much easier to share macro using SAS autocall facility instead of stored compiled macro catalogs.  The files for an autocall library are just text files with SAS code in them. They are very portable.

[YUXI]

Hey Tom, thanks for your comment, and I need to say I am not quite familiar with SAS. I guess now I could explain it to you better now:

• So, this is the SAS MACRO FILE I have metioned before. I find it is the "catalog" type (in the "property"). I guess this should be the thing you said "stored compiled macro", and it do have many macros inside:

• And I'm sure that this "stored compiled macro" was coded and created by author in SAS 9.4 with his own laptop. And, if others want to use this macro, they just download this sas7bcat file into their own laptop. By using SAS 9.4 in their own laptop, they can easily call macros like this:

• At before, our group members can only use SAS 9.4 in their own laptop. These days, we bought a Windows Server (work station?) and built a SAS server system in it, and group members use SASEG 8.3 im their own PC (remotely connected to the server)

• So, as before, we still want to use this "stored compiled macro".  And I just put this "stored compiled macro" (sasmacr.sas7bcat) into the Windows Server, and the directory is "D:\SASMacro". I guess when a group member use SASEG 8.3, he can also easily call macros in this "stored compiled macro" (remotely though).
• But this time, it cannot work, and the code I run in the SASEG 8.3 like this:

(the warning is as below, warning 2/3 don't matter too much)

• Commonly, after running this %sumtest, there should be an output dataset with some numbers. But this time, with this warning, there is no number in the dataset. Weird!

So I'm not sure if this is as what you said "use a stored compiled macro on a version of SAS running on Windows Server you probably need to have created the stored compiled macro on that machine and not be trying to access a verison compiled on a different version of SAS."

Besides, does this means if I still want to use this "stored compiled macro" (sasmacr.sas7bcat) in our remote SAS system, I need to let macro author re-compile his macros in the SAS 9.4 (Windows Server Version)? 

[Kurt_Bremser]

Because of certain grave limitations of catalog files (they are dependent on operating system, underlying hardware, and SAS version), macros should (IMO MUST) be disseminated as SAS program (.sas) files, which work everywhere, and can be used with a simple %INCLUDE, or by copy/pasting the text into your EG program window.

Get back to the source and demand the macro as SAS program file.

[YUXI]

Make sense! It should work! I will try %include ".sas" to call macros later.

[YUXI]

Oh, I just forgot to say: Thanks for your comment ：）

[YUXI]

But I find that a new problem has arisen: if %INCLUDE is used to call a ".sas" file, the source code of the MACROs can be easily discovered by others. Using a compiled catalog eliminates this risk of leakage. How can this problem be solved?

Additionally, if the author is able to recompile the MACROs on SAS WinServer as a new encrypted catalog  (rather than his own PC), will there still be a problem with calling it on SASEG?

[Kurt_Bremser]

Recompiling the macros is of course possible.

But you have to make sure that the original source of the macros is always available for your company/institution. Relying on compiled and encrypted macros without access to the source is a recipe for disaster.

[Tom]

Additionally, if the author is able to recompile the MACROs on SAS WinServer as a new encrypted catalog  (rather than his own PC), will there still be a problem with calling it on SASEG?

That sounds like the first test you should do.  Then you will know if the issue is with accessing the macro or with the actual SAS code that the macro is generating.

But I find that a new problem has arisen: if %INCLUDE is used to call a ".sas" file, the source code of the MACROs can be easily discovered by others. Using a compiled catalog eliminates this risk of leakage. How can this problem be solved?

You seem have stated the issue backwards there.  If you use a stored compiled macro the PROBLEM is that the users CANNOT SEE THE SOURCE CODE so they cannot tell if the macro is doing what it is supposed to do.  Not sure what leakage is, but if you are concerned that the source code will modified than use operating system file permissions to make the file readonly so that no one can accidentally modify the file.

[AlanC]

First of all, I agree on keeping SAS code out of compiled macros and doing %includes. I can't tell you how many times I have seen this in the field (as a consultant) and the original source is lost.

There is no way to stop your source code from being discovered. You can compile it, encrypt it, etc. but ultimately it has to be executed. As soon as it goes to plain text for execution, it is discoverable. You can also back into the original (somewhat) using logs and logging mechanisms. The binary in the compiled file is also discoverable. 

Your best bet to hide code is to use a form of service and keep the executing code on a different machine. However, that complicates the architecture.

Compiled macros are an archaic SAS storage mechanism: do not use them. 

[Tom]

So from looking at some of the photographs of text you posted (why go to the trouble to create and upload photographs to share text?) it definitely looks like the macro is using the %SYSGET() function.  Unless that disconnected image is a message generated by some other code you ran then it also appears that the macro catalog is working fine.  It is just that the macro itself is not working.

You can use the SET option to modify environment variables in your SAS session.  So if you know how the macro works and what it is expecting as environment variables then perhaps you can get it to work.

https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/hostwin/p01905399zwlc4n115yaey6jt871.htm

[Quentin]

I think the pictures show that you are able to successfully invoke the macro.  So it sounds like you successfully transferred the macro catalog from your laptop to the server, and the macro processor is still able to read an execute the macros.  That is believable, since your laptop and your server are both windows.  If you have other macros in the same catalog, you could test them.

The problem is not related the the macro processor / macro catalog, it's related to the macro itself.  The macro is executing, and when the macro executes it generates an error.

This is where you will likely be stuck for a while, unfortunately.  It is very hard (impossible?) to debug a macro without having access to the macro code.  If there is very detailed documentation for the macro, you might be able to guess at some possibilities.  If you still have PC SAS running and the macro works there, you could turn on options MPRINT SYMBOLGEN MLOGIC and run the macro, and that might give you some clues as to the name of the environment variable that may be missing on your server.  But you're still stuck trying to debug code without having the code.