BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
ScottBass
Rhodochrosite | Level 12

I'd like to use stored processes to create a series of crude user interface windows in EG.  I know about the prompting manager, but I want to encapsulate the many separate UI objects in each window via stored processes.

 

In my testing, I created the stored process to run under Workspace server only and chose my default EG workspace server as the Applicationserver. However, since they run under different SAS sessions, passing data between the two sessions is problematic.

 

What are my options for passing data between the two sessions?  One approach I can think of is to use dictionary.macros to save the desired macro variables to a permanent SAS dataset, say sasuser.foo, then use a data _null_ step in the EG workspace server session to retrieve those macro variables.  I'd prefer to use a temporary dataset, say a stored process session dataset, but I don't know how to pass the pathname for that dataset to the EG workspace server session.  But I suppose the processing in the workspace server session could delete the sasuser dataset, thus making that dataset transient anyway.

 

Any other approaches that I could use?  Or is the above approach the best one to use?


Please post your question as a self-contained data step in the form of "have" (source) and "want" (desired results).
I won't contribute to your post if I can't cut-and-paste your syntactically correct code into SAS.
1 ACCEPTED SOLUTION

Accepted Solutions
ChrisHemedinger
Community Manager

Scott,

 

I think that's the best you can do -- share info via secondary storage (file or data set).  The two sessions (Workspace and STP) don't share any other space in common -- no shared memory, plus no way to connect from one discrete session to another (like a SAS/CONNECT mechanism).

 

You're using SASUSER, which isn't always available for write within an EG session.  By "shared WORK" I mean simply another folder on disk that you designate as a temporary work space, but that you keep around for the life of ALL sessions (where the built-in WORK library disappears when the current SAS session exits).  You would have to manage the lifespan/assignment of that shared work library.

 

SAS Grid Manager does something similar with GRIDWORK, a WORK-like library that all sessions on the various grid nodes can access so that information can pass from one worker node to another.  

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.

View solution in original post

3 REPLIES 3
ChrisHemedinger
Community Manager

I was going to suggest looking into PROC OPTSAVE and OPTLOAD as part of a holistic approach, but as I was searching for examples -- I found one by you!

 

In terms of passing data, usually we rely on a shared WORK lib, sort of like GRIDWORK for SAS Grid Computing.  That allows multiple sessions to have access to "transient" data while a job is running.  You could use something similar for STP and Workspace server sessions, I guess.

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
ScottBass
Rhodochrosite | Level 12

Thanks Chris...

 

1) I'm not sure what you mean by "shared WORK lib"?  BTW, I'm not the SAS Admin, and doubt he'd change the configuration for this.

 

2) In the past, I used a similar process to what I want now, with web stored processes and batch processing.  I wrote a macro to support this:  https://github.com/scottbass/SAS/blob/master/Macro/stp_batch_submit.sas.  (The default background processing did not give me the control I desired).  

 

The macro uses a transient STP session dataset to pass the STP generated macro variables to the spawned SAS session.  It passes the pathname for the session dataset to the spawned SAS session via the sysparm parameter.  The spawned SAS code has a simple data _null_ step at the beginning of the program to recreate the macro variables, then proceeds as though it were the code of the stored process.  However, in EG, I don't know of any way to pass information between the two sessions except for external files (dataset or flat file).

 

3) I *can* get this to work right now.  The code is something like:

 

Stored Process:

 

proc sql noprint;
   create table sasuser.parms as
   select name,value
   from dictionary.macros
   where upcase(name) like 'BATCH_%' /* use whatever mvar prefix you want */
   ;
quit;

EG Program:

 

data _null_;
   set sasuser.parms;
   call symputx(name,value,'G');
run;

/*
proc delete data=sasuser.parms;
run;
*/

%dump_mvars(batch_test1 batch_test2)

I just wanted to know if this is best practice, as good as any other approach?


Please post your question as a self-contained data step in the form of "have" (source) and "want" (desired results).
I won't contribute to your post if I can't cut-and-paste your syntactically correct code into SAS.
ChrisHemedinger
Community Manager

Scott,

 

I think that's the best you can do -- share info via secondary storage (file or data set).  The two sessions (Workspace and STP) don't share any other space in common -- no shared memory, plus no way to connect from one discrete session to another (like a SAS/CONNECT mechanism).

 

You're using SASUSER, which isn't always available for write within an EG session.  By "shared WORK" I mean simply another folder on disk that you designate as a temporary work space, but that you keep around for the life of ALL sessions (where the built-in WORK library disappears when the current SAS session exits).  You would have to manage the lifespan/assignment of that shared work library.

 

SAS Grid Manager does something similar with GRIDWORK, a WORK-like library that all sessions on the various grid nodes can access so that information can pass from one worker node to another.  

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

SAS Enterprise Guide vs. SAS Studio

What’s the difference between SAS Enterprise Guide and SAS Studio? How are they similar? Just ask SAS’ Danny Modlin.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 3 replies
  • 1331 views
  • 1 like
  • 2 in conversation