I thought I had sent this to the list earlier today, but seems not to have
been proceesed (or i forgot to hit send? : ).
1. Full disclosure: I *like* mergenoby=error, and like the idea of it
being on by default. There are few times that I intentionally code a
smush, and when I do, I'm happy to make it obvious that it is intended;
options mergenoby=nowarn; *smush coming!;
merge a a (keep=id rename=(id=nextid) firstobs=2)
options mergenoby=error; *no accidental smushes allowed!;
When I call a macro written long ago, occasionally I might get an error
message if the macro created SAS code that did a smush. I like this. It
tells me I should review the macro. If the smush is intended, I can
modify the macro code to reset the option within the macro, or I can leave
the macro as is and change my call to be:
2. It seems to me with UNIX, as on PC, you can have a user-specified
autoexec and/or config. So even if the corporate standard
is "mergenoby=error", you could tell individual users how to set their own
defaults (if that is "allowable").
3. If that is not allowable, you could set the default to be
mergenoby=error and start running code. When you find a legacy program
that does a smush, then add "options mergenoby=nowarn" to the top.
4. If #3 seems a silly idea, maybe identify all of your legacy code. Then
write a SAS pogram/perl (?) script/whatever that will insert into the top
of each program:
put "NOTE: this is legacy code that may contain legitimate use of merge
without a by statement";
This documents the legacy code (which we assume does not have any mistaken
omissions of by statements), and over time the legacy code could be
On Thu, 18 Mar 2004 12:00:50 -0500, SAS User <sas@SDAC.HARVARD.EDU> wrote:
>I have been horribly outvoted here regarding our system default
>for the new mergenoby option. I have stood firm on the philosophy
>that you do not alter user's defaults for them, despite how
>beneficial it might be. You can strongly request that they alter
>their own defaults, sure. I even suggested that we could poll
>everyone for their preference, and set up a script to invoke
>SAS with one of the three options for this option, depending on
>the users id and their response to the poll. This change had
>been discussed at several meetings, where I eventually gave in
>and accepted that we will change the default to warning.
>Unfortunately, I was away for the last meeting where the big-shots
>here decided that they want the system-wide option to be set
>I absolutely refused to do this, as this will cause programs to
>halt that were correct (in very rare instances here, yes).
>I don't see the benefit here to have ERROR over WARNING for this
>option. I haven't yet heard their reasons for this, but I'm
>assuming that it involves the exit status (UNIX system here-
>most stats run processes in the background to get an exit status)
>or the fact that bad programmers might just search a log file
>for the string ERROR. But you shouldn't alter a default to
>stop a program because of syntax that might be appropriate because
>of bad programming and lazy log-checkers.
>I'm emailing the list because I have been so outvoted on these
>issues (as the only programmer against all statisticians), so
>I'm hoping that folks out there might have stronger arguments
>than I have gathered. I need to have some mighty ammo for the
>next meeting. Example: We discussed setting the compress
>default to yes, until we learned that our old version of DBMS
>copy can not read compressed SAS datasets. Any arguments
>regarding mergenoby would be greatly appreciated.