Hi, We submit our stored processes via the Stored Process Web Application.  My particular stored process is using prompts to provide a user interface to the user.  However, since the actual processing can take a long time (30-60 minutes) to run, the "heavy lifting" is done by a SAS job running in batch.  The actual results will be emailed back to the user as a PDF attachment. Since the code isn't that long, I've included it below.  What I'd like to know is if this is best practice, or if there is a better approach?  In particular, the documentation says: _ACTION Used By Web Clients Description Specifies an action for the Web application to take. Possible values for this variable are as follows: BACKGROUND executes the stored process in the background. Can someone explain what this means exactly?  How is "background" different than "not background"?  The documentation doesn't make this clear. Here's the code: Stored Process (the prompts are dynamic lists based on SASHELP.SHOES for Region, Subsidiary, and Product): %STPBEGIN; OPTIONS VALIDVARNAME=ANY; *  End EG generated code (do not edit this line); /* Set all necessary macro variables. If they are macro variables that you want sent to the batch job, best practice is to create them all with the same prefix. I am using the prefix "batch_". Otherwise you need to change the PROC SQL code below. */ * macro variables sent to the batch job ; %let batch_username = &_username; %let batch_jobname  = Test SAS Batch Job; /* Create a Stored Process (STP) session, which allocates the temporary SAVE library. This library is used to pass parameters between the STP and the batch job. While we are creating the STP session, also create the confirmation message. Note that the "email when the job finishes" must be generated by the batch job, not this Stored Process. */ data message;   * session timeout is in seconds - 2 minutes should be plenty ;   if _n_ = 1 then do;     if libref('SAVE') ne 0 then do;       rc = stpsrv_session('create',2*60);     end;   end;   infile datalines truncover;   input message $200.;   keep message;   datalines4; Job &batch_jobname submitted at %sysfunc(strip(%sysfunc(datetime(),datetime18.))). You will receive an email when the job finishes. ;;;; run; libname save list; /* This macro variable must be set AFTER the session is created. */ %let batch_save_library=%sysfunc(pathname(save)); /* Now copy the desired parameters (macro variables) to the SAVE library. This dataset will be used by the batch job to recreate the macro variables. */ proc sql noprint;   create table save.parameters as     select       name       ,value     from       dictionary.macros     where       name like 'BATCH_%'   ; quit; /* Setup the parameters for invoking SAS, then launch the SAS job. You MUST pass in the path to the SAVE library location via sysparm. My preference is to use a configuration file, rather than command line options, with ALL other job configuration (eg. -sysin) done in the configuration file. This gives the maintainer of the code ONE place to go to change the batch job options. However, you can configure this however you wish. */ %let sas=C:\SAS\Config\Lev1\SASApp\sas.bat; %let config=&batch_config_file;  /* if you have created a hidden STP parameter,                                     otherwise hard code this here */ %let sysparm=&batch_save_library; %let options=; * invoke the SAS batch job ; systask command "&sas -config &config -sysparm ""&sysparm"" &options" nowait; /* Now display the confirmation message to the user. The options nomerror and noserror suppress warning messages in the log for unresolved macro and unresolved macro variable references. HTML code in particular can have tokens (eg. &program=...) that look like macro variables but are HTML tokens instead. */ %let options=%sysfunc(getoption(merror,keyword)) %sysfunc(getoption(serror,keyword)); options nomerror noserror; data message;   set message;   message=resolve(message); run; options &options; title; options nonumber nodate; proc report data=message nowd noheader center ls=96 spacing=0;   columns message;   define  message / width=96 " "; run; *  Begin EG generated code (do not edit this line); ;*';*";*/;quit; %STPEND; *  End EG generated code (do not edit this line); And here's a sample SAS batch job: /* Allocate the SAVE library passed in via sysparm */ libname save "%scan(&sysparm,1,%str(^|))"; /* Set macro variables passed in to the batch job by the Stored Process */ data _null_;    set save.parameters;    call symputx(name,value,"G"); run; /* The rest of your program goes here... You would process the macro variables just like you would in a stored process. */ * Print macro variables ; options nocenter; proc sql;   select     name,value   from     dictionary.macros   where     name like 'BATCH_%' and scope="GLOBAL"   order by     name   ; quit; * Print SASHELP.SHOES filtered on input parameters ; * Note:  %stp_seplist processes the STP parms, creating a separated list ; options mprint; %macro stp;   %local where;   %let where=%sysfunc(sum(&batch_region_count,&batch_product_count,&batch_subsidiary_count));   options noserror nomerror;   data subset;     set sashelp.shoes;     %if (&where) %then %do;       where 1     %end;     %if (&batch_region_count) %then %do;       and region in (%stp_seplist(batch_region))     %end;     %if (&batch_product_count) %then %do;       and product in (%stp_seplist(batch_product))     %end;     %if (&batch_subsidiary_count) %then %do;       and subsidiary in (%stp_seplist(batch_subsidiary))     %end;     %if (&where) %then %do;       ;     %end;   run;   options serror merror;   proc print;   run; %mend; %stp /* Send email that the job has finished. */ * Create message dataset ; data mail;    length parm $15 line $1000;    infile datalines dsd dlm="|" truncover;    input parm line;    datalines4; | Your SAS job &batch_jobname has completed with return code rc=&sysrc.. ;;;; run; %sendmail(to=&batch_username,subject=%str(Job &batch_jobname has completed),content_type=text/html) ... View more

Hi, I admit, I don't use EG much, but my end users do.  So they have hundreds of saved projects.  Yesterday I made a change to the metadata, which broke their saved projects.  Luckily, changing it back fixed the issue. For the sake of this discussion, say I have this library defined in metadata: Object Name: "My Library" Object Id:   A5LKTB5E.AY00002D Libref:      mylib Path:        C:\Temp\mylib We recently migrated that library to SPDE, but want to keep the old library object around for a bit (performance comparisons).  So, I changed the old library object to: Object Name: "My Library - BASE" Object Id:   A5LKTB5E.AY00002D  (unchanged) Libref:      mylib_b Path:        C:\Temp\mylib_base And created this new library object:: Object Name: "My Library - SPDE" Object Id:   A5LKTB5E.AY000020 Libref:      mylib Path:        C:\Temp\mylib_base IOW, I wanted to transparently migrate the users to the SPDE library, but I also renamed the library objects to make it clear which one was being used. I was surprised that EG is using the library object *name* as the pointer to the library, and that changing the name would break the projects.  Renaming "My Library - SPDE" to "My Library" fixed the issue with the saved EG projects. In Base SAS, a dataset is referenced by libref.dataset, so changing the definition of the libref, but not the libref itself, would seamlessly change the datasets being referenced. If I recall correctly, DI Studio uses the library object id in its jobs, so that changing a library object name in metadata would not break the job.  (I'm going on memory here) So why is there a third way to reference libraries in EG?  I would have thought either the underlying libref (my preference) or underlying object id (to be consistent with DIS) would have been used. I'm sure there's a good design reason why the library object name is used, but I can't think of it.  So what is that good reason??? Lesson learned though:  once you create a library object in metadata that is used in EG projects, you're stuck with the name.  So choose wisely .  Of course, the same principle applies to choosing a libref in base SAS programming. Regards, Scott ... View more

Hi, 1) I have to move various log files from our default location on C: to another drive due to disk space issues. We have these logs in C:\SAS\Config\Lev1\Web\Logs: RemoteServices.log RemoteServices_wrapper.log SASBIWebServicesforJava9.2.log SASContentServer.log SASPreferences9.2.log SASStoredProcess9.2.log SASWIPServices9.2.log SASWIPSoapServices9.2.log How can I relocate these log files to another directory?  I've edited C:\SAS\Config\Lev2\Web\Applications\RemoteServices\wrapper.conf and log4j.properties.  Will this affect the location of all these files? 2) Finally, I've changed the log settings for SASApp --> SASApp - SAS DATA Step Batch Server, but it seems to me that that doesn't really have any effect, and I'll need to change the -log parameter on all our batch programs.  (I'm not really sure what the SASApp - SAS DATA Step Batch Server server setting in SMC buys me; it seems like the SAS invocation parameters of the ETL batch job would take priority). Any help, esp. for #1, greatly appreciated. Regards, Scott ... View more

Hi, SAS 9.2 on Windows I need to ensure a dataset for a marketing mailout does not inadvertently contain customers already submitted previously.  To accomplish this, I delete any customer numbers from today's mailout that are contained in any previous mailout. To accomplish this, I was hoping to use a permanent data step view to concatenate all the previous mailouts, then use PROC SORT NODUPKEY on the concatenated view, then delete those records contained in the PROC SORT output. However, I'm not getting the desired outcome.  It appears that the dataset list is NOT dynamic, but in fact is compiled into the view at compile time.  IMO this behaviour is a bug.  Does anyone else agree before I raise a support track? data d_1 d_2 d_3;   x=1; run; data all/view=all;   length dsname $32;   set d_: indsname=dsn;   dsname=scan(dsn,2); run; proc print data=all; run; data d_4;   x=1; run; proc print data=all; run; proc delete data=d_2; run; proc print data=all; run; The view does not print the d_4 data, and it fails if d_2 is deleted.  If I select "describe view" in SAS Explorer, it indicates the set statement contains a dataset list, which I would have expected would be evaluated at run time, not compile time.  If nothing else, it's very misleading. Thanks, Scott ... View more