Adapt collectcode option for non-standard location of autoexec files

[cttnguyen]

I was able to use your package calling SAS from a corporate server, and so far it's been awesome!
I had to set several of the SAS options, where basically everything is in a different location: SAS, the SAS config file, and the autoexec file, and my working directory.

To do so, I had been using the following in my sasopts. This works fine when I don't want to use collectcode. The sysparm options are for setting certain system environment parameters that are required for this particular autoexec file.

"-autoexec /serverpath/autoexec.sas -sysparm var1=sysparam1,var2=sysparam2"

If I understand correctly how collectcode works, then applying the option to a code chunk will write that code chunk to the end of the autoexec. However, this is not working in my situation where my autoexec does not exist within my working directory and cannot be edited in its original directory. My current workaround is to make a new autoexec. It looks something like this, where I had to set some environment variables that are needed for passing through to the autoexec.

%let var1=sysparam1;
%let var2=sysparam2;
%include "/serverpath/autoexec.sas";

Would it be possible to expand this function to additionally look for the autoexec in a defined location, then write and use a temporary new autoexec file with the arguments for the autoexec and system parameters?

[Hemken]

Well, the sysparm you can set as a command line option, in the code chunk where you load the SASmarkdown library. The autoexec is an interesting question. SAS ordinarily looks for an autoexec in several places, but only uses the first one it finds. In contrast, SAS will happily make use of several config files. What sorts of SAS commands are in the autoexec? (Great workaround, by the way.)

…

________________________________ From: cttnguyen ***@***.***> Sent: Thursday, February 9, 2023 11:54:38 AM To: Hemken/SASmarkdown ***@***.***> Cc: Subscribed ***@***.***> Subject: [Hemken/SASmarkdown] Adapt collectcode option for non-standard location of autoexec files (Issue #25) I was able to use your package calling SAS from a corporate server, and so far it's been awesome! I had to set several of the SAS options, where basically everything is in a different location: SAS, the SAS config file, and the autoexec file, and my working directory. To do so, I had been using the following in my sasopts. This works fine when I don't want to use collectcode. The sysparm options are for setting certain system environment parameters that are required for this particular autoexec file. "-autoexec /serverpath/autoexec.sas -sysparm var1=sysparam1,var2=sysparam2" If I understand correctly how collectcode works, then applying the option to a code chunk will write that code chunk to the end of the autoexec. However, this is not working in my situation where my autoexec does not exist within my working directory and cannot be edited in its original directory. My current workaround is to make a new autoexec. It looks something like this, where I had to set some environment variables that are needed for passing through to the autoexec. %let var1=sysparam1; %let var2=sysparam2; %include "/serverpath/autoexec.sas"; Would it be possible to expand this function to additionally look for the autoexec in a defined location, then write and use a temporary new autoexec file with the arguments for the autoexec and system parameters? — Reply to this email directly, view it on GitHub<#25>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACYBME2TIHFT6T6BMT2Q2ILWWUVN5ANCNFSM6AAAAAAUW3MENQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[cttnguyen]

Well, the sysparm you can set as a command line option, in the code chunk where you load the SASmarkdown library.

Do you have an example of this? I'm worried that the system parameter would be set in the R working directory while knitting and not the SAS/server working directory when setting up the SAS session for the job.

I'm pretty novice at SAS, and looking through how our SAS server and autoexec files are organized, I'm completely lost.

Some of the arguments going in are things such as my user id and additional paths to more autoexec files that are project-specific. As in there's a high level autoexec file to define set up for any user, followed by project-level files to further tailor the set up such that all programmers on the same project are in sync with one another.

[Hemken]

For the sysparm options I mean something like: library(SASmarkdown) sasopts <- paste(knitr::opts_chunk$get()$engine.opts$sas, "-sysparm var1=sysparam1,var2=sysparam2") knitr::opts_chunk$set(engine.opts=list(sas=sasopts, saslog=sasopts), comment=NA) (Here I’ve only defined this for the sas and saslog engines – if you use other kinds of output, you would want to define those engines as well.) Building on your workaround for the autoexec (sounds like we’d rather not look inside there!), in the first chunk where you collect code, I might do ```{sas chunklabel, collectcode=TRUE, echo=-1} %include /serverpath/autoexec.sas; /* more sas code */ ``` With these two fixes, you shouldn’t have to write any additional files to go alongside your document. Doug Hemken Statistical consultant Social Science Computing Cooperative Univ. of Wisc. – Madison ***@***.******@***.***> 608-262-4327 From: cttnguyen ***@***.***> Sent: Friday, February 10, 2023 9:08 AM To: Hemken/SASmarkdown ***@***.***> Cc: Doug Hemken ***@***.***>; Comment ***@***.***> Subject: Re: [Hemken/SASmarkdown] Adapt collectcode option for non-standard location of autoexec files (Issue #25) Well, the sysparm you can set as a command line option, in the code chunk where you load the SASmarkdown library. Do you have an example of this? I'm worried that the system parameter would be set in the R working directory while knitting and not the SAS/server working directory when setting up the SAS session for the job. I'm pretty novice at SAS, and looking through how our SAS server and autoexec files are organized, I'm completely lost. Some of the arguments going in are things such as my user id and additional paths to more autoexec files that are project-specific. As in there's a high level autoexec file to define set up for any user, followed by project-level files to further tailor the set up such that all programmers on the same project are in sync with one another. — Reply to this email directly, view it on GitHub<#25 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACYBMEZGBRVZTBP23BID6PDWWZKVJANCNFSM6AAAAAAUW3MENQ>. You are receiving this because you commented.Message ID: ***@***.***>

[cttnguyen]

Oh I see. Yes that's what I had been doing prior to testing with collectcode:

sasopts <- paste0(
  c(
    "-sysparm var1=%s,var2=%s",
    "-config %s",
    "-autoexec %s",
    "-noterminal",
    "-work %s",
    "-print %s",
    "-nonews"
  ),
  collapse = " "
) %>% 
  sprintf(
    sysparam1, sysparam2,
    config_path,
    autoexec_path,
    wd_path,
    wd_path
)

I moved both the autoexec and sysparm options to the new autoexec file, but you're right that I could leave the sysparm in my sasopts. I still have to create the temporary autoexec, although it now just has %include "/serverpath/autoexec.sas"; in it.