Macro causing to show the jobs status to FAILED

[Akshay_93]

Hello,

We've the below macro defined in appserver_autoexec_usermods.sas which is helpful when accessing spreadsheets, csv files and access DB files when using PC File Server.

/* Macro defined in appserver_autoexec_usermods.sas */
%global srv;
data _null_;
     call symput("srv",compress("&_CLIENTMACHINE"));
     run;

/* EXAMPLE of reading a Spreadsheet */
PROC IMPORT DBMS=excelcs
	OUT=test_import 
DATAFILE="\\location\abc\pqr\xyz\excel test.xlsx" REPLACE;
	PORT=9621;
	SERVER=&srv;
	serveruser="&da_lanid";
	serverpass="&da_pwd";
RUN;

ISSUE:

Users are able to read in and write the files using PC File server successfully. But in the Workspace server logs we see a message saying, 

WARNING: Apparent symbolic reference _CLIENTMACHINE not resolved.

Due to this warning message, we're getting the state of all jobs as FAILED even though the job was ran successfully.

We don't wan't to ask all the Users in our environment to their change their code to access files when using PC File Server.

How to overcome this scenario without reinstalling EG? 

Please suggest!

SAS 9.4 M6 with SWO

Thanks. 

[SASKiwi]

What server is your SAS PC File Server running on? The SERVER= parameter should specify this server, not every SAS users's client PC which is what that macro variable is trying to define.

[Akshay_93]

Not possible in our case, because we've Enterprise Guide installed on 4 servers and it is presented through VMHorizon Client to the Users(VMHC is similar to Citrix).
VMHC has the ability to load balance and connect to the server which has less traffic.

[SASKiwi]

What OS do your SAS servers run on? If it is Windows you don't need the SAS PC Files Server. If it is Unix/Linux you can read/write XLSX files also without the PC Files Server. Do you use MS Access databases which would still require use of the PC Files Server?

[Akshay_93]

Linux x64.

Yes, Sir. We do use PC File Server to connect to Access Database. We just replace the DBMS value to ACCESSCS.

[SASKiwi]

So is the SAS PC Files Server running on each of the VMs hosting EG? If it is running on the same computer as EG then I don't think you need to specify the SERVER= option.

[Akshay_93]

Yes, we've it running on each. As we're importing/exporting Office files on different machines we're using SERVER=option.

Correct me if I'm wrong!

[SASKiwi]

AFAIK, the SERVER= option is to identify the Windows server the SAS PC Files Server is running on, not the server where the Office files are stored. Those can be accessed by any accessible file share.from the Windows server the SAS PC Files Server is running on. In your case it would be a lot simpler to have the SAS PC Files Server installed on one Windows server and the SERVER= option can then be hardcoded. There is no reason this shouldn't work in a VM setup like you have.

[Tom]

I don't understand what you are trying to do. 

It sounds like you are trying to use some macro variable set by Enterprise Guide named _CLIENTMACHINE.  Are you sure that is the right variable that reflects the machine where Enterprise Guide is running?

Now even if it is the right machine are you sure that is the machine you want?  If the users are running something like Citrix to run Enterprise Guide then the machine where EG is running is the Citrix server and not their individual PC.  Is that machine running PC Files Server?

If the users can be assigned to one of many different Citrix servers then why does it matter which Citrix server you use to run PC Files Server?  Why not just run that on one machine and have each SAS program access that one machine?  Then you don't need to know what machine Enterprise Guide is running on.  That machine does not even have to be one of the Citrix servers, it just needs to run PC Files Server and have access to the files they users need to read/write.

[gwootton]

Could you add a SYMEXIST check before trying to set srv in your autoexec?

https://go.documentation.sas.com/?docsetId=mcrolref&docsetTarget=n1j6dly37s4370n14hdiznpbxso4.htm&do...

[Akshay_93]

Hey @gwootton ,

Tried SYMEXIST and we still see the warning message.

%global srv;
data _null_;
     if symexist("_CLIENTMACHINE") then
        call symput("srv",compress("&_CLIENTMACHINE"));
     else
        call symput('abc','abc');
     run; 

Any suggestions on how to get rid of "_CLIENTMACHINE"?

[gwootton]

How about:

%global srv;
%macro clientmachine;
%if %symexist(_clientmachine) %then %let srv=&_clientmachine;
%mend;
%clientmachine;

[Akshay_93]

Almost worked!!!

We no longer see the WARNING message in the logs, but when ran a %put &srv; the client machine is read as blank by which we're failing to import/export Office files.

Here is the error we get when trying to exporting a spreadsheet.

30         PROC EXPORT DATA= test
31         OUTFILE= "\\location\abc\pqr\xyz\excel test.xlsb"
32         DBMS=EXCELCS REPLACE;
33         sheet="test";
NOTE: The previous statement has been deleted.
34         port=9621;
35         server=&srv;
                      _
                      22
ERROR 22-322: Syntax error, expecting one of the following: a name, a quoted string.  

36         serveruser="&da_lanid";
37         serverpass="&da_pwd";
38         RUN;

ERROR: Failed to connect to the Server: NAME.
NOTE: The SAS System stopped processing this step because of errors.
NOTE: PROCEDURE EXPORT used (Total process time):

[gwootton]

It sounds like the variable _CLIENTMACHINE is not set when the macro runs, so it isn't setting the value.
Since _CLIENTMACHINE is being set by the client (Enterprise Guide for example) it wouldn't be present until after the autoexec files on the server are run.
If you call the %clientmachine macro again before your code does it function?

[SASKiwi]

Does it work correctly if you hardcode the server name?