#201 Improvement idea: Handling global environment variables in main ans subsessions.

[Csanád Lévay]

Hello!

We use SASUnit for SAS testing, and it's a great framework, however I was wondering if global parameter handling could be enchanced. The problem is, we run SASUnit as batch, and when we call the run_all.sas we create global parameters, which are not passed to the subsessions of the scenarios. I checked, and there are some global parameter handling in the target.tsu dataset, which is nice. On the other hand you have to define the global parameters beforehand so that the localenvironment.sas macro can load it. I created a solution which saves all the existing global parameters, when initSASUnit.sas is called in the dataset target.glb. I also modified the looadenvironment.sas macro, so it recreates the global parameters in the subsession from target.glb (excluding the ones which exist in the subsession as local). You can find this in the following code if you search it for "LCS:". I think this solution could be beneficial because all the global environment variables are passed from the main session to the subsessions of the scenarios.

Please, tell me what you think about this idea.

Kind regards,
Csanád

[Csanád Lévay]

Here is the part where I save the global parameters. Search "LCS:" for exact place.

[Klaus Landwich]

Hi Csanád,

thanks for your input. I appreciate your contribution. Your approach is worth thinking about.

For SASUnit we had a different approach for passing global parameters ito the scenario session.
You can use a autoexec file to set them and pass this on to the scenario sessions.
See parameter i_autoexec of initSASUnit. The autoexec file is used to start the scenario sessions.
Please verify if that too solves your problem.

If not, then we could use a process similar to your suggestion. I would prfer to have a parameter to enumerate the global variables that you like to pass on. This prevents SASUnit from setting own global macro variables twice. And gives you more control over what the session is knowing.

Regards
Klaus

[Csanád Lévay]

Hi Klaus,

Thank you, for the fast answer. I forgot to mention, but I checked that all the subsessions invoke the autoexec, passed from the main session, however running the autoexec is only a solution if the parameters are in the autoexec or I can recreate the parameters with information provided from the autoexec. This would mean I have to put some runtime parameters (like run date of the session) in the autoexec which is suboptimal for operational use. Another solution could have been, that I create windows system variables from my global variables, which can be accessed by the subsession. My problem with this was, that it probably would have been a bit complex to store the information of how many system variables have been created, and which variables I need to load in the subsession. That's why I decided it would be the best to create a new SAS dataset to store these infos, since I saw it in the code that global parameters are stored and reloaded this way in SASUnit (but it was hard coded).
To clarify things, we are using IBM Flow Manager (sometimes called LSF, which is a flow runner, monitoring software prefered by SAS) and we pass the run date parameter through LSF parameter which then invokes the main session of SASUnit (the run date is neccessary to filter tables according to the run date in the scenarios). We have a process (a sas macro) which can extract the LSF run date parameter, but this can only be done by a session which was invoked by LSF itself. Because the scenarios are invoked by local command files (as far as I understood) and not LSF, we lose the information what the run date was, so I had to solve, how to pass this information to the subsessions. I understand that this is a pretty special case in itself, however I thought it would be a good idea to share my solution, since running the subsessions with the same default global parameter set as the main session are often beneficial.

Kind regards,
Csanád

[Klaus Landwich]

Hi Csanád,

now I got your point.

There still is a solution to your problem.

You could write an autoxec file on the fly, note the parameters therein and pass it on to initSASUnit.

I did that myself already in the SASUnit self tests to prove that i_config is working.
I update the SASUnit provided config file with -autoexec "<filename>".</filename>

In run_all.sas I addes the followinf lines:

%let ConfigName   =%sysfunc (pathname(work))/config_for_testing.cfg;
%let AutoexecName1=%sysfunc (pathname(work))/autoexec_for_config_test.sas;

data _null_;
   file "&ConfigName.";
   infile "%sysget(SASUNIT_ROOT)/bin/sasunit.%sysget(SASUNIT_SAS_VERSION).%lowcase(%sysget(SASUNIT_HOST_OS)).%lowcase(%sysget(SASUNIT_LANGUAGE))_junit.cfg" end=eof;
   input;
   put _INFILE_;
   if (eof) then do;
      put "-autoexec ""&AutoexecName1.""";
   end;
run;

data _null_;
   file "&AutoexecName1.";
   put '%LET HUGO=Test for i_config;';
run;

Is that possible for your situation?

I'm confident with your solution. Except that I prefer to have more control over what information is passed on.
Because there are other possiblilties to achieve the same I would not yet add it to SASUnit.

Regards
Klaus

[Csanád Lévay]

Dear Klaus,

Excuse me for taking so long to answer. I found your solution is well suited for my needs, and it doesn't involve modifying the core code. I will use this onwards, thank you for your help! :)

Regards,
Csanád