Date: Thu, 18 Mar 2004 16:19:22 -0500
Reply-To: Sigurd Hermansen <HERMANS1@WESTAT.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Sigurd Hermansen <HERMANS1@WESTAT.COM>
Subject: Re: mergenoby: opinions/arguments?
Quentin's workaround and typically thoughtful arguments would take care of
my earlier objection to the 'ERROR' option. Come to think of it, I have
reluctantly used the MERGE/NO BY method only twice during the past year, but
I have encountered the 'no ON statement' error message in SQL JOIN's many
times. One has to work at it to specify a Cartesian JOIN in SAS SQL if one
uses the JOIN operators. The results of SAS NO BY MERGE's tend to be easier
to create and harder to detect.
Of course a logical person might reach the conclusion that a better way to
avoid NO BY MERGE's would be to use SAS SQL for database programming tasks.
While SAS SQL does not prevent dumb or careless programming, as I know too
well, it does take the mystery out of combining rows of datasets.
From: Quentin McMullen [mailto:quentin_mcmullen@BROWN.EDU]
Sent: Thursday, March 18, 2004 3:36 PM
Subject: Re: mergenoby: opinions/arguments?
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
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
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.