1
votes

I've got a executable file (without source files, only .exe file) which I am trying to run in a .sas file, using a file reference to an unnamed pipe:

%macro process_file(path);
    %let filepath = %trim(&path.);
    %let filename = %scan(&path., -1, %str(\));

    filename flf pipe "&progpath. ""&filepath."" ""&workpath.\&filename..log""";

    data hnd_tmp;
        length line $1024.;
        infile flf; input;
        line = left(trim(compbl(_infile_)));    
    run;
%mend process_file;

This script basically returns a list of processes which are blocking a particular file (filepath) and returns output to the log file (the third argument).

When I run my code in SAS 9.3 it works well and I receive a desired output, but when I use SAS Enterprise Guide 5.1, the script throws an exception:

Unhandled Exception: System.Exception: Could not list processes locking resource. Failed to get size of result.
    at ProcessHelpers.FileUtil.WhoIsLocking(String path)
    at ConsoleApplication1.Program.start(String[] args)
    at ConsoleApplication1.Program.Main(String[] args

I cannot debug the application, so this exception tells me almost nothing.

I am wondering if there are any differences between running programs in SAS BASE and SAS Enterprise Guide in terms of e.g. environmental variables, system options etc. - something that could possibly lead to the program throwing an exception.

I have been looking for a solution in SAS documentation and papers but with no luck so far.

Do you have any ideas? Thanks in advance.

Edited to provide more details, see comments.

The solution has been tested directly on a networked server and the program throws an exception. I can replicate this situation on a RACE Virtual Machine locally and locally on a server as well. All the servers are running on Windows. Hardcoding the commands did not help, still there's an issue. XCMD is turned on. It seems to be a problem with invoking the code not locally.

1
System variables, path, etc are probably different through EG. Can you execute X commands to echo those values and see if something is different from when you log in directly?DomPazz
@DomPazz: I am not exactly sure what do you mean by "X commands", I've run a code do get all macro variables both from BASE and EG and I am trying to examine them and find differences. Available here @ pastebin.gczarnocki
X <command>; runs an OS command from SAS. It works like the PIPE Filename you are using. You could run some OS echos to see what is different between the environments. If that is the problem, then you can get your admin to help you fix it.DomPazz
When you run it in EG, are you still connecting to 'local SAS server' or are you connecting to a (networked) SAS server?Joe
Also, try taking the macro code out of the equation. Hardcode the commands that the macro is generating and check to see if it runs on both. In other words, come up with the simplest possible command that you can to make it fail, so that you can rule out everything else.Robert Penridge

1 Answers

0
votes

If the code is successful in Base SAS (on the target machine), and unsuccessful in an EG session connected to run on that same Server, then I'd suspect an issue with user permissions.

It is possible to launch an interactive Base SAS session with the same configuration as an EG (remote client) session, using a shell command - eg as follows:

"C:\SAS\Config\Lev1\SASApp\WorkspaceServer\WorkspaceServer.bat" -terminal -splash

Try logging onto the RACE image as the same user you are connecting with in EG (sasdemo?) and run your code in the BASE SAS session launched from the command above.

  • If this is unsuccessful (error message), the issue is server side, and most likely username permissions.
  • If your filename pipe works above, then I'd make double sure you are actually connecting to that same workspace server in your EG session (check your connection profile).

To summarise, yes there ARE differences, mainly in the .cfg file, but may also be found in the various _usermods files used in creating the final SAS launch command. Just follow the contents of the .bat file above to see them.