How do I identify how SAS options are set in different environments? SAS 9.4

[qaguy1982]

This might belong in SAS administration.   Looking for a way to identify environmental options as SAS batch on a Server is giving me different results than when I run the same program on demand in my local SAS installation on my PC.

BACKGROUND:

We have a situation whereby a macro attempts to drop a field from an input dataset.   Due to certain data attributes, we have found that this data item does not exist for some groupings of data.   (An original data set is transposed, but one row we expected does not exist so the column is not created on the resulting post-transpose dataset.)

When we run the program in batch mode submitted on our SAS server, the system stops processing and does not create the expected data set.   System sets OBS=0 and the program quits processing and does not create any output.  ( A pdf report with a table report and a supplemental bar chart.)

However when we bring the program down to run on a local SAS workstation for debugging,  we still get the error on the missing drop field, but the SAS system continues to run the rest of the program.   We get to the end and create output - admittedly it is not the output we would expect but the report completes.

The data set that should have been created does not replace the one left over from a prior pass through the macro so a lot of values are not calculated correctly as we are using the prior data as we continue through the program.

ISSUE:

I am trying to figure out why the SAS system operates differently and what options I might have to modify to make the report work the same in both environments.   

Is there a way to list all SAS options and what their settings are in each environment?   I tried running Proc Options but that just seems to show a list of options.  I can't tell if it is just listing all options, or if the options listed are what is set on the system.  

[ballardw]

If you submit as part of your job:

Proc options;

run;

The log will have all the system options set.

You could even make a batch job that only runs that to have a simpler log.

Then run the same thing in an interactive session and compare.

[qaguy1982]

More information:

I ran proc options on the errorhandling group in both environments and both results are identical.  I had hoped it would be something like one option was set one way on one environment and differently in the other.

proc options group=(errorhandling);
run;

So now my question is,  is there something else I need to look into? perhaps batch vs on demand processing options?

[data_null__]

You need to show more details about the EXACT error you are getting.  I will guess that one or both of these options may be useful to you.

DKRICOND= System Option

Specifies the level of error detection to report when a variable is missing from an input data set during the processing of a DROP=, KEEP=, or RENAME= data set option

DKROCOND= System Option

Specifies the level of error detection to report when a variable is missing for an output data set during the processing of a DROP=, KEEP=, or RENAME= data set option.

[CarmineVerrell]

If on linux use appropriate software to startup sh.

Click Close

In the Editor enter the following code

Proc options;

Run;

Also make sure you take a look at the log, at this point try also running the entire program too.

[Reeza]

Pipe the SASHELP.VOPTION view to a data set from each system and run a PROC COMPARE on them.
Take a look at the ERROR ABEND

>The data set that should have been created does not replace the one left over from a prior pass through the macro so a lot of values are not calculated correctly as we are using the prior data as we continue through the program.

Use PROC DATASETS at the end of your macro to delete temporary data sets so that they don't cause this issue. If the numbers were wrong but in the right ballpark you can easily miss an error like this. I illustrate that idea in this macro at the end - commented out as I only uncomment it once testing is complete. https://gist.github.com/statgeek/353374a5d8ea4f0c89ce5d80a47f4a4c

[SASKiwi · Accepted solution]

@qaguy1982  - The reason for the difference is the SAS option SYNTAXCHECK is set by default in batch sessions, but NOSYNTAXCHECK is set for interactive SAS sessions. 

[qaguy1982]

DIng, ding, ding. We have a winner. In the long run we still need to identify the real bug and fix it. My customer was complaining that a report was coming up blank. But when I tested it locally, the output was created and not blank. Very confusing. Thanks for the assist.

[SASKiwi]

@qaguy1982  - Easy to test SYNTAXCHECK locally by adding - options syntaxcheck; - to the start of your program. Personally I love this option for batch programs because the jobs fail fast and the evidence of the failure is kept. 

[Reeza]

Use PROC DATASETS at the end of your macro to delete temporary data sets so that they don't cause this issue. If the numbers were wrong but in the right ballpark you can easily miss an error like this. I illustrate that idea in this macro at the end - commented out as I only uncomment it once testing is complete. https://gist.github.com/statgeek/353374a5d8ea4f0c89ce5d80a47f4a4c

[Tom]

If you have an expected structure then build that into your process.

For example you might have a saved template dataset that has all of the variables.  You could then use something like this to fix the output of your PROC TRANSPOSE.

proc transpose ... out=step4 ....

data step5;
  if 0 then set template;
  set step4;
run;

Or you could add an extra group of observations into the dataset you are transposing.  So make an extra level of your BY group and make sure it has one observation for every variable you need created.  You can then drop that observation from the output dataset.

data step3 ;
  set template step2;
run;
proc transpose data=step3 out=step4(where=(not missing(id))) ;
  by id;
  ....
run;