LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (March 2004, week 3)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
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?
Comments: To: Quentin McMullen <quentin_mcmullen@BROWN.EDU>
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


Back to: Top of message | Previous page | Main SAS-L page