BookmarkSubscribeRSS Feed

I assert that the warning received when using the outobs= option in PROC SQL is inconsistent with other SAS options, such as firstobs=, obs=, [startobs=, endobs= (spde engine)].  Yes, I know they are input not output options.

 

I further assert the warning is unnecessary since I explicity coded the outobs= option.  Why warn me for something I've explicitly chosen?

 

Finally, numerous Google hits will show that end users find the warning to be user unfriendly.

 

The undocumented NOWARN option to PROC SQL will suppress the warning, but this suppresses other warnings that I might be interested in.

 

So just get rid of the outobs= warning as a bad idea that's been fixed by SAS 😉

 

If there's a good reason why the warning exists that overrides the above reasoning please let me know.

 

(And does anyone know why SAS chose startobs= and endobs= for the SPDE engine instead of firstobs= and obs=?  They appear to do the same thing, and any differences are so subtle that the different syntax seems unnecessary.)

6 Comments
paulkaefer
Lapis Lazuli | Level 10

My counterarguments are:

    (1) that it's a warning. It won't do anything to execution, so can't you just ignore it?

    (2) isn't there a way to systematically suppress warnings?

    (3) I've used outobs= for testing purposes. For example, I don't want to process all of the thousands/millions of records in a given dataset. Having a warning is a way to flag that I'm still using outobs, even if what I actually want is to process everything (for example, if I moved my development code into production.

 

If it's still something you don't want to see, I would much prefer to an option instead of removing the warning altogether.

ScottBass
Rhodochrosite | Level 12

My counterarguments are:

    (1) that it's a warning. It won't do anything to execution, so can't you just ignore it?  SB:  No, many sites have coding standards that require no warnings in the SAS log.

    (2) isn't there a way to systematically suppress warnings?  SB:  Not that I'm aware of.

    (3) I've used outobs= for testing purposes. For example, I don't want to process all of the thousands/millions of records in a given dataset. Having a warning is a way to flag that I'm still using outobs, even if what I actually want is to process everything (for example, if I moved my development code into production.  SB:  Weak argument but fair enough.  What if you left the data set options firstobs= and obs= in your development code?  Why the special treatment for the SQL outobs= behaviour?  And at some point the developer has to be responsible for his/her own code, usually via unit testing.

 

If it's still something you don't want to see, I would much prefer to an option instead of removing the warning altogether.  SB:  Fair enough.  The undocumented NOWARN option is too all-encompassing.  But, what happens when you have outobs= and (say) the nowarnoutobs SQL option in your code that you promoted to production?  The warning is again suppressed.

 

I just don't see the use for the warning, and removing it would be more consistent with other areas of SAS.  My opinion only, YMMV.  It would be good to get others' opinions on this as well.

ChrisNZ
Tourmaline | Level 20

SAS really needs to provide fine-grained options to choose how log messages are treated.

 

An oversize SAS/Graph title is not worth a warning.

A merge by with non-unique keys is usually worthy of a warning rather than a note.

 

As production environments become more stringent, this becomes an increasingly burning issue.

 

 

As for the startobs= and endobs= / firstobs= and obs= options,they all have their place and should be available to all engines imho.

 

The main difference is that  firstobs= and obs= are applied after a where clause is applied (so they limit the filtered data) , whereas startobs= and endobs= are applied before a where clause.

 

Note that obs= should be called lastobs= anyway, as many users believe is means "nb of obs to read" rather then "obs no where to stop reading" [position vs quantity, no vs nb].

 

Can we create the alias lastobs= please SAS?

 

 

 

 

 

 

 

DaveShea
Lapis Lazuli | Level 10

Rather belatedly, I support Scott's idea to remove the WARNING when Proc SQL executes with an OutObs=xxx option. I think it should also be extended to the InObs=xxx option.

 

I could live with a NOTE but a WARNING seems too harsh and I try very hard with users that I deal with, to get them to pay attention to ERRORs and WARNINGs, I tell them that they are there for a reason. Having to then say "oh, yeah, don't worry about those WARNINGs"  rather loses the message of checking the SASLOG.

 

Finally, I prefer not to use undocumented features. Once they are part and parcel of the software, that's great, but I don't like leaving a tree-root for someone else to find, especially when its likely to have my name on it Man Wink.

 

Cheers,

 

Downunder Dave.

hnb_matt_d
Obsidian | Level 7
proc sql nowarn outobs=25;

That works...  I know this is an older string, but I found it while researching same.  

DaveShea
Lapis Lazuli | Level 10

Hi @hnb_matt_d,

 

Thanks for your comment, but as I have said previously, as the NOWARN is an undocumented feature, I prefer not to use it in code as this can lead to problems if the undocumented feature is then withdrawn in later releases of SAS.

 

What I am looking for is something similar to the NOWARNRECURS option which changes a WARNING to a NOTE in the SASLOG when a table in the FROM clause is referenced in the CREATE TABLE clause.

 

Cheers,

 

Downunder Dave.