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?
Content-Type: text/plain
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.
Sig
-----Original Message-----
From: Quentin McMullen [mailto:quentin_mcmullen@BROWN.EDU]
Sent: Thursday, March 18, 2004 3:36 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: mergenoby: opinions/arguments?
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
