|
Hi Casey,
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!;
data b;
merge a a (keep=id rename=(id=nextid) firstobs=2)
run;
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:
options mergenoby=nowarn;
%macroWithSmush()
options mergenoby=error;
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";
options mergenoby=nowarn;
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
reviewed.
Kind Regards,
--Quentin
On Thu, 18 Mar 2004 12:00:50 -0500, SAS User <sas@SDAC.HARVARD.EDU> wrote:
>Hello SAS-lers,
>
>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
>to ERROR.
>
>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.
>
> -Casey
| 
