Executing EGP with Powershell - Unable to get SAS code

[QuentinWk]

Hello !

I have been struggling with a problem for a few months and still have no clue how to solve it.

On our platform, we execute scheduled powershell scripts to run SAS EG projects (egp). Example provided :

$sas=New-Object -ComObject SASEgObjectModel.Application.7.1;
$sas.SetActiveProfile('SAS94');

$App=$sas.open("\\path\myProject.egp", "" );

Try {
    $App.run();
}
Catch{
}
Finally{
    $App.close();
    $sas.quit();
}

Among dozens of scripts executed, we have one in particular getting the following error :

1          ;*';*";*/;quit;run;
2          OPTIONS PAGENO=MIN;
3          %put ERROR: Unable to get SAS code. Could not find a part of the path
3        ! 'C:\Users\zsvcsas\AppData\Local\Temp\SEG7320\e39a62d916d74b9fa15ea3bb9626cd8a\code.sas'.;
ERROR: Unable to get SAS code. Could not find a part of the path 
'C:\Users\zsvcsas\AppData\Local\Temp\SEG7320\e39a62d916d74b9fa15ea3bb9626cd8a\code.sas'.
4          
5          QUIT; RUN;

It seems like during the execution of the different parts of the EGP, SEG loses the track of at least one program.

I found very few information on the internet about this error, excepting http://support.sas.com/kb/62/237.html.

Following the SAS note we redirected the temporary directories for SEG : it changed nothing. I can publish the new error message if needed (in which you'll see the new Temp directory).

There is one last essential thing. This project will encounter the error :

• Everytime it runs on Monday 6 a.m.
• Everytime it runs on Friday 4 a.m.

But works perfectly :

• Any other day
• Everytime it runs on Monday 19 p.m.

I can't find any explanation about how this error can be related to a specific project, and a specific moment. I know this might be very specific, but I need to understand the nature of this error and what it means. I can't see why a SEG project can repeatedly lead SEG to lose the track of one "code.sas" file (and still work perfectly at other times).

[ChrisHemedinger]

From the error, it looks like this is happening when running a task or query -- not a custom SAS program.

EG will generate that error if it can't generate the SAS code from a task/query.  Usually the cause for that is that it can't get to the data that serves as input to the task or query.

Anything about the data that might make this less accessible at those times?  Same user account running all of the jobs?

Enabling Application Logging (Tools->Options) might help too.  This will generate a PowerShell.exe.nnn.log file in the user profile of the account running the job, with lots of details.  Might need Tech Support help to decipher.

[QuentinWk]

Hi, thanks Chris for the answer !

Unfortunately the unique process flow in this project actually contains only custom SAS programs. In the log I can clearly see the 5 first SAS programs executed correctly. After what we encounter the error program after program.

I compared an OK execution with a KO. What should appear is :

1          ;*';*";*/;quit;run;
2          OPTIONS PAGENO=MIN;
3          %LET _CLIENTTASKLABEL='Virements IDIT';
4          %LET _CLIENTPROCESSFLOWNAME='Flux de processus';
5          %LET _CLIENTPROJECTPATH='xxx\xxx\project.egp';
6          %LET _CLIENTPROJECTPATHHOST='SN782877';
7          %LET _CLIENTPROJECTNAME='project.egp';
8          %LET _SASPROGRAMFILE='';
9          %LET _SASPROGRAMFILEHOST='';
10         
11         ODS _ALL_ CLOSE;
12         OPTIONS DEV=PNG;
13         GOPTIONS XPIXELS=0 YPIXELS=0;
14         FILENAME EGSR TEMP;
15         ODS tagsets.sasreport13(ID=EGSR) FILE=EGSR
16             STYLE=HtmlBlue
17             STYLESHEET=(URL="file:///C:/Program%20Files/SASHome/SASEnterpriseGuide/7.1/Styles/HtmlBlue.css")
18             NOGTITLE
19             NOGFOOTNOTE
20             GPATH=&sasworklocation
21             ENCODING=UTF8
22             options(rolap="on")
23         ;
NOTE: Writing TAGSETS.SASREPORT13(EGSR) Body file: EGSR
24         
25         GOPTIONS ACCESSIBLE;
26         /*
27         	Beginning of SAS program number 6
28         */

And what we get is (as shown in the first post) :

1          ;*';*";*/;quit;run;
2          OPTIONS PAGENO=MIN;
3          %put ERROR: Unable to get SAS code. Could not find a part of the path
3        ! 'C:\Users\zsvcsas\AppData\Local\Temp\SEG7768\47b50f31078d4687a9a8fc978bc32d8d\code.sas'.;
ERROR: Unable to get SAS code. Could not find a part of the path 
'C:\Users\zsvcsas\AppData\Local\Temp\SEG7768\47b50f31078d4687a9a8fc978bc32d8d\code.sas'.
4          
5          QUIT; RUN;
6          

And that is true for every other SAS program until the end of the process flow. The ERROR block is the same, except for the exact directory betwen "SEG7768" and "code.sas".

In addition, I don't understand why the path begins with "C:\Users\zsvcsas\AppData\Local\Temp" as we have modified seguide.exe.config (http://support.sas.com/kb/62/237.html) and redirected Temp directories to another location. I checked the new directory and there are tmp files appearing every day so the redirection has to be working at least partially.

[ChrisHemedinger]

Puzzling! How about enabling the Application Log?  That might yield some additional info from the failed jobs.

[QuentinWk]

Yes I will enable Application Log before the next run in order to collect more details. I will post my findings here afterwards.

[QuentinWk · Accepted solution]

Finally and with the help of SAS Technical Support, we found something.

We first tried to schedule our SAS EG project with a VBS script and no powershell : the error was still there. Then we focused on the fact that our file SEGuide.exe.config contained redirected variables for temporary directories (http://support.sas.com/kb/62/237.html), but the project elements seemed to stay in the default TEMP directory.

We modified the Windows environment variables (TEMP and TMP) for the user running the powershell script. After that, the project completed successfully and did not encounter conflict anymore. The conclusion is that the workaround in SAS Note 62237 works but since the SAS EG powershell API do not take into account the parameters in SEGuide.exe.config, you have to change the windows environment variables too.