sas >> Trap a warning?

by bjohnson » Wed, 10 Sep 2003 04:57:19 GMT

I'm writing a program to do a merge, and I want to look for an instance
where the BY fields are of differing lengths. SAS generates this message:
WARNING: Multiple lengths were specified for the BY variable MDID by input
data sets. This may cause unexpected results.
How can I programmatically look for this warning and either send a message
to the listing, or stop the program?

Thanks for your help (as always)

_______________________________
Bruce A. Johnson
Senior Data Analyst
Solucient, LLC
(847) 440-9635
XXXX@XXXXX.COM



This message is a private communication. It may contain information that is
confidential and legally protected from disclosure. If you are not an
intended recipient, please do not read, copy or use this message or any
attachments, and do not disclose them to others.

Please notify the sender of the delivery error by replying to this message,
and then delete it and any attachments from your system. Thank you.
Solucient LLC.

sas >> Trap a warning?

by bjohnson » Wed, 10 Sep 2003 05:34:11 GMT


Interestingly, I found that using a SQL merge, rather than a datastep
bypasses the variable length issue....

________________________________
Bruce A. Johnson
XXXX@XXXXX.COM


-----Original Message-----
From: Chakravarthy, Venky [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 4:12 PM
To: XXXX@XXXXX.COM
Subject: Re: Trap a warning?


Bruce,

I have done something like the following before. You can add code to abort
further processing.

proc sql noprint ;
select length into : lenof1 separated by " "
from dictionary.columns
where libname = "WORK" and
memname = "FIRST" and
name = "MYBYVAR" ;

select length into : lenof2 separated by " "
from dictionary.columns
where libname = "WORK" and
memname = "SECOND" and
name = "MYBYVAR" ;
quit ;

%macro warnme ;
%if &lenof1. ^= &lenof2. %then
%put WARNING: Unequal lengths of BY Variables. STOP. ;
%mend warnme ;

%warnme

Kind Regards,
_________________________________
Venky Chakravarthy
E-mail: swovcc_AT_hotmail_DOT_com

-----Original Message-----
From: Bruce Johnson [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 4:57 PM
To: XXXX@XXXXX.COM
Subject: Trap a warning?


I'm writing a program to do a merge, and I want to look for an instance
where the BY fields are of differing lengths. SAS generates this message:
WARNING: Multiple lengths were specified for the BY variable MDID by input
data sets. This may cause unexpected results. How can I programmatically
look for this warning and either send a message to the listing, or stop the
program?

Thanks for your help (as always)

_______________________________
Bruce A. Johnson
Senior Data Analyst
Solucient, LLC
(847) 440-9635
XXXX@XXXXX.COM



This message is a private communication. It may contain information that is
confidential and legally protected from disclosure. If you are not an
intended recipient, please do not read, copy or use this message or any
attachments, and do not disclose them to others.

Please notify the sender of the delivery error by replying to this message,
and then delete it and any attachments from your system. Thank you.
Solucient LLC.


LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be
privileged. It is intended for the addressee(s) only. Access to this E-mail
by anyone else is unauthorized. If you are not an addressee, any disclosure
or copying of the contents of this E-mail or any action taken (or not taken)
in reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately.


This message is a private communication. It may contain information that is
confidential and legally protected from disclosure. If you are not an
intended recipient, please do not read, copy or use this message or any
attachments, and do not disclose them to others.

Please notify the sender of the delivery error by replying to this message,
and then delete it and any attachments from your system. Thank you.
Solucient LLC.

sas >> Trap a warning?

by jdesho01 » Wed, 10 Sep 2003 06:32:18 GMT

f you really have two tables where a key variable in both has different
lengths, the field is probably padded in one dataset and not in the
other. If that's the case, you'd be better off specifying a length
statement at the top of the offending data step to adjust the variables
to the same length (either through padding or truncation, whichever is
appropriate).

When a length statement is the very first statement in a data step --
BEFORE the merge statement -- it takes precedence over the lengths of
the variables in the input tables.

It would look like this:

data myoutfile;
length keyfield $ 15;
merge
file1 (in = in_file1)
fiel2 (in = in_file2);
by keyfield;
run;



Joe DeShon
Manager, Advanced Applications Development
PCS Marketing & Sales Analysis Group
Sprint PCS
6130 Sprint Parkway
Mailstop: KSOPHJ0114-1A504
Overland Park KS 66251
Work: (913) 762-6172
PCS: (816) 210-0950
Fax: (913) 762-0804
email: XXXX@XXXXX.COM


-----Original Message-----
From: Bruce Johnson [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 4:34 PM
To: XXXX@XXXXX.COM
Subject: Re: Trap a warning?

Interestingly, I found that using a SQL merge, rather than a datastep
bypasses the variable length issue....

________________________________
Bruce A. Johnson
XXXX@XXXXX.COM


-----Original Message-----
From: Chakravarthy, Venky [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 4:12 PM
To: XXXX@XXXXX.COM
Subject: Re: Trap a warning?


Bruce,

I have done something like the following before. You can add code to
abort
further processing.

proc sql noprint ;
select length into : lenof1 separated by " "
from dictionary.columns
where libname = "WORK" and
memname = "FIRST" and
name = "MYBYVAR" ;

select length into : lenof2 separated by " "
from dictionary.columns
where libname = "WORK" and
memname = "SECOND" and
name = "MYBYVAR" ;
quit ;

%macro warnme ;
%if &lenof1. ^= &lenof2. %then
%put WARNING: Unequal lengths of BY Variables. STOP. ;
%mend warnme ;

%warnme

Kind Regards,
_________________________________
Venky Chakravarthy
E-mail: swovcc_AT_hotmail_DOT_com

-----Original Message-----
From: Bruce Johnson [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 4:57 PM
To: XXXX@XXXXX.COM
Subject: Trap a warning?


I'm writing a program to do a merge, and I want to look for an instance
where the BY fields are of differing lengths. SAS generates this
message:
WARNING: Multiple lengths were specified for the BY variable MDID by
input
data sets. This may cause unexpected results. How can I programmatically
look for this warning and either send a message to the listing, or stop
the
program?

Thanks for your help (as always)

_______________________________
Bruce A. Johnson
Senior Data Analyst
Solucient, LLC
(847) 440-9635
XXXX@XXXXX.COM



This message is a private communication. It may contain information that
is
confidential and legally protected from disclosure. If you are not an
intended recipient, please do not read, copy or use this message or any
attachments, and do not disclose them to others.

Please notify the sender of the delivery error by replying to this
message,
and then delete it and any attachments from your system. Thank you.
Solucient LLC.


LEGAL NOTICE
Unless e

sas >> Trap a warning?

by Ralph Winchell » Wed, 10 Sep 2003 09:16:37 GMT

roc SQL is your friend. Get to know it and love it, and watch your
productivity skyrocket.




XXXX@XXXXX.COM (Bruce Johnson) wrote in
news: XXXX@XXXXX.COM :



sas >> Trap a warning?

by Venky.Chakravarthy » Thu, 11 Sep 2003 00:26:04 GMT

agree with "Proc SQL is your friend". There are places where SQL code is
handy and is preferred over the data step code. However, in this case the
WARNING issued by the data step is for good reason. Multiple lengths can
cause unexpected results. More importantly, it may alert you that one of the
input data sets has an unexpected length assignment and thus identify the
source quickly. Let us consider a case where the BY variable in one of the
data sets is assigned a length smaller than one of its values. Further let
us assume that such a length assignment was not the coders intent but a
typo.

data q ;
length x $1 ; /* typo for $10 */
x = "abcdefghij" ;
run ;

data w ;
length x $10 ;
x = "abcdefghij" ;
run ;

data qw ;
merge q w ;
by x ;
run ;

You get this in the log:
<<<
WARNING: Multiple lengths were specified for the BY variable X by input data
sets. This may cause unexpected results.

So when you issue a print, the above warning helps you in understanding the
truncation of the value to a single character and the reason that it
considered the two X values equal.

title "Unexpected Result" ;
options nocenter ;
proc print ;
run ;

Unexpected Result
09:24 Wednesday, September 10, 2003 1

Obs X

1 a

Contrast this to the SQL log:

16 proc sql ;
17 select q.x
18 from q , w
19 where q.x = w.x ;
NOTE: No rows were selected.
20 quit ;

Which log is better in helping debug?

Also take a look at Bob Virgile's SUGI 28 paper:

Danger: MERGE Ahead! Warning: BY Variable with Multiple Lengths!

http://www2.sas.com/proceedings/sugi28/098-28.pdf

Kind Regards,
_________________________________
Venky Chakravarthy
E-mail: swovcc_AT_hotmail_DOT_com

-----Original Message-----
From: Ralph Winchell [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 9:17 PM
To: XXXX@XXXXX.COM
Subject: Re: Trap a warning?


Proc SQL is your friend. Get to know it and love it, and watch your
productivity skyrocket.




XXXX@XXXXX.COM (Bruce Johnson) wrote in
news: XXXX@XXXXX.COM :


sas >> Trap a warning?

by Roland » Thu, 11 Sep 2003 20:13:38 GMT


the
data
the

Interesting article. I have a macro that generates the length statements for
character variables using the maximum length. Additionally, it will use the
case of the variable in the first data set in the list of data sets since
this could also vary. Also, if there is no disagreement in character
variable lengths then that variable will not be in the length statement. If
all character variables lengths are consistent then the length statement is
blank. You use it like this:

%clength(ds1 ds2 ds3);
data all;
&_clength_;
set ds1 ds2 ds3;
run;

http://www.datasavantconsulting.com/roland/clength.sas

sas >> Trap a warning?

by WHITLOI1 » Thu, 11 Sep 2003 21:59:48 GMT

ruce,

I would recommend

Danger: MERGE Ahead!
Warning: BY Variable with Multiple Lengths!
Bob Virgile
Robert Virgile Associates, Inc.

http://www.nesug.org/Proceedings/nesug03/at/at005.pdf

A merge message with different length key indicates sloppy programming. SQL
is a fine tool. (SQL cannot issue a message here because the power of the
tool is too great to make it an error.) However, if it is used to avoid the
message instead of fixing the problem, I would view it as a more serious
offense than simply sloppy.

XXXX@XXXXX.COM
-----Original Message-----
From: Bruce Johnson [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 5:34 PM
To: XXXX@XXXXX.COM
Subject: Re: Trap a warning?


Interestingly, I found that using a SQL merge, rather than a datastep
bypasses the variable length issue....

________________________________
Bruce A. Johnson
XXXX@XXXXX.COM


-----Original Message-----
From: Chakravarthy, Venky [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 4:12 PM
To: XXXX@XXXXX.COM
Subject: Re: Trap a warning?


Bruce,

I have done something like the following before. You can add code to abort
further processing.

proc sql noprint ;
select length into : lenof1 separated by " "
from dictionary.columns
where libname = "WORK" and
memname = "FIRST" and
name = "MYBYVAR" ;

select length into : lenof2 separated by " "
from dictionary.columns
where libname = "WORK" and
memname = "SECOND" and
name = "MYBYVAR" ;
quit ;

%macro warnme ;
%if &lenof1. ^= &lenof2. %then
%put WARNING: Unequal lengths of BY Variables. STOP. ;
%mend warnme ;

%warnme

Kind Regards,
_________________________________
Venky Chakravarthy
E-mail: swovcc_AT_hotmail_DOT_com

-----Original Message-----
From: Bruce Johnson [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 4:57 PM
To: XXXX@XXXXX.COM
Subject: Trap a warning?


I'm writing a program to do a merge, and I want to look for an instance
where the BY fields are of differing lengths. SAS generates this message:
WARNING: Multiple lengths were specified for the BY variable MDID by input
data sets. This may cause unexpected results. How can I programmatically
look for this warning and either send a message to the listing, or stop the
program?

Thanks for your help (as always)

_______________________________
Bruce A. Johnson
Senior Data Analyst
Solucient, LLC
(847) 440-9635
XXXX@XXXXX.COM



This message is a private communication. It may contain information that is
confidential and legally protected from disclosure. If you are not an
intended recipient, please do not read, copy or use this message or any
attachments, and do not disclose them to others.

Please notify the sender of the delivery error by replying to this message,
and then delete it and any attachments from your system. Thank you.
Solucient LLC.


LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be
privileged. It is intended for the addressee(s) only. Access to this E-mail
by anyone else is unauthorized. If you are not an addressee, any disclosure
or copying of the contents of this E-mail or any action taken (or not taken)
in reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately.


This message is a priv

sas >> Trap a warning?

by bjohnson » Thu, 11 Sep 2003 22:22:03 GMT

understand what you're saying about being sloppy. The situation I'm being
presented with is a physician database that been created a while ago.
Subsequently, a patient dataset has been created without any knowledge of
that physician dataset. There is a need to make these two databases merge
as automatically as possible. Since the people processing the patient
dataset don't know anything about the physician dataset, and vice versa, I
wanted to see if there was a way to flag the situation where the merge
produced the WARNING and stopped the program, allowing the analyst to adjust
the length accordingly.

________________________________
Bruce A. Johnson
XXXX@XXXXX.COM


-----Original Message-----
From: Ian Whitlock [mailto: XXXX@XXXXX.COM ]
Sent: Thursday, September 11, 2003 9:00 AM
To: 'Bruce Johnson'; XXXX@XXXXX.COM
Cc: ' XXXX@XXXXX.COM '
Subject: RE: Trap a warning?


Bruce,

I would recommend

Danger: MERGE Ahead!
Warning: BY Variable with Multiple Lengths!
Bob Virgile
Robert Virgile Associates, Inc.

http://www.nesug.org/Proceedings/nesug03/at/at005.pdf

A merge message with different length key indicates sloppy programming. SQL
is a fine tool. (SQL cannot issue a message here because the power of the
tool is too great to make it an error.) However, if it is used to avoid the
message instead of fixing the problem, I would view it as a more serious
offense than simply sloppy.

XXXX@XXXXX.COM
-----Original Message-----
From: Bruce Johnson [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 5:34 PM
To: XXXX@XXXXX.COM
Subject: Re: Trap a warning?


Interestingly, I found that using a SQL merge, rather than a datastep
bypasses the variable length issue....

________________________________
Bruce A. Johnson
XXXX@XXXXX.COM


-----Original Message-----
From: Chakravarthy, Venky [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 4:12 PM
To: XXXX@XXXXX.COM
Subject: Re: Trap a warning?


Bruce,

I have done something like the following before. You can add code to abort
further processing.

proc sql noprint ;
select length into : lenof1 separated by " "
from dictionary.columns
where libname = "WORK" and
memname = "FIRST" and
name = "MYBYVAR" ;

select length into : lenof2 separated by " "
from dictionary.columns
where libname = "WORK" and
memname = "SECOND" and
name = "MYBYVAR" ;
quit ;

%macro warnme ;
%if &lenof1. ^= &lenof2. %then
%put WARNING: Unequal lengths of BY Variables. STOP. ;
%mend warnme ;

%warnme

Kind Regards,
_________________________________
Venky Chakravarthy
E-mail: swovcc_AT_hotmail_DOT_com

-----Original Message-----
From: Bruce Johnson [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 4:57 PM
To: XXXX@XXXXX.COM
Subject: Trap a warning?


I'm writing a program to do a merge, and I want to look for an instance
where the BY fields are of differing lengths. SAS generates this message:
WARNING: Multiple lengths were specified for the BY variable MDID by input
data sets. This may cause unexpected results. How can I programmatically
look for this warning and either send a message to the listing, or stop the
program?

Thanks for your help (as always)

_______________________________
Bruce A. Johnson
Senior Data Analyst
Solucient, LLC
(847) 440-9635
XXXX@XXXXX.COM


sas >> Trap a warning?

by WHITLOI1 » Thu, 11 Sep 2003 23:03:19 GMT

ruce,

I would suggest looking at the data to find out if it makes sense to match
on the variables you are planning to match. For example, if ID has length
of 3 in one file and 200 in another, but no value is more than 3 nonblank
characters it may make sense to merge and the situation is merely sloppy.
If you find, for example 123 on the first file and 123000 123001 123003 etc.
on the second file you may want to find out why? In short you have to know
what the data looks like and why it got that way in order to know how to
handle the situation.

MERGE takes the length from the first file. If the file with the longer
length is placed first there will be no message since no data is truncated.
Just like SQL, MERGE leaves it to the programmer to decide whether a merge
makes sense. When the short length file is placed first, values from the
second file will be truncated. It is that fact which triggers the message.

XXXX@XXXXX.COM

-----Original Message-----
From: Bruce Johnson [mailto: XXXX@XXXXX.COM ]
Sent: Thursday, September 11, 2003 10:22 AM
To: XXXX@XXXXX.COM
Subject: Re: Trap a warning?


I understand what you're saying about being sloppy. The situation I'm being
presented with is a physician database that been created a while ago.
Subsequently, a patient dataset has been created without any knowledge of
that physician dataset. There is a need to make these two databases merge
as automatically as possible. Since the people processing the patient
dataset don't know anything about the physician dataset, and vice versa, I
wanted to see if there was a way to flag the situation where the merge
produced the WARNING and stopped the program, allowing the analyst to adjust
the length accordingly.

________________________________
Bruce A. Johnson
XXXX@XXXXX.COM


-----Original Message-----
From: Ian Whitlock [mailto: XXXX@XXXXX.COM ]
Sent: Thursday, September 11, 2003 9:00 AM
To: 'Bruce Johnson'; XXXX@XXXXX.COM
Cc: ' XXXX@XXXXX.COM '
Subject: RE: Trap a warning?


Bruce,

I would recommend

Danger: MERGE Ahead!
Warning: BY Variable with Multiple Lengths!
Bob Virgile
Robert Virgile Associates, Inc.

http://www.nesug.org/Proceedings/nesug03/at/at005.pdf

A merge message with different length key indicates sloppy programming. SQL
is a fine tool. (SQL cannot issue a message here because the power of the
tool is too great to make it an error.) However, if it is used to avoid the
message instead of fixing the problem, I would view it as a more serious
offense than simply sloppy.

XXXX@XXXXX.COM
-----Original Message-----
From: Bruce Johnson [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 5:34 PM
To: XXXX@XXXXX.COM
Subject: Re: Trap a warning?


Interestingly, I found that using a SQL merge, rather than a datastep
bypasses the variable length issue....

________________________________
Bruce A. Johnson
XXXX@XXXXX.COM


-----Original Message-----
From: Chakravarthy, Venky [mailto: XXXX@XXXXX.COM ]
Sent: Tuesday, September 09, 2003 4:12 PM
To: XXXX@XXXXX.COM
Subject: Re: Trap a warning?


Bruce,

I have done something like the following before. You can add code to abort
further processing.

proc sql noprint ;
select length into : lenof1 separated by " "
from dictionary.columns
where libname = "WORK" and
memname = "FIRST" and
name = "MYBYVAR" ;

select length into

Similar Threads

1. Trapping errors

Hi.

I have a process with several data and proc steps, all bound and up and
tethered in a macro.  Every now and then, one of the steps may fail,
leading to a bunch of error messages from subsequent steps that depended
on the errant output of the step that first failed.  I'd like to be able
to control the execution of subsequent steps based upon the success or
failure of previous steps.  But SAS doesn't seem to have a uniform way of
doing this.  I know some of the codes I can check:
For libname statements, check &syslibrc.
For data step errors, check &syserr.  &syserr also appears to work for at
least some PROC SQL errors.
The documentation mentions &syslckrc for lock statements.
There's also &sysrc, but I don't know whether that gives any error
information.

Right now I'm particularly interested in trapping errors from:
data step,
libname,
proc datasets,
proc format,
proc optsave,
proc optload,
proc sort,
proc sql,
proc summary,
proc surveyselect

so if anyone can tell me how to trap errors from these procedures I'd
certainly appreciate it (especially if they're not fully covered by syserr
and syslibrc).  Also, this list is sure to expand.  Is there a document
that collects all or most of the information on how to trap errors from
various SAS procedures?

Thanks!

--  TMK  --
"The Macro Klutz"

2. Trapping errors in Proc IML

3. Error Trap

Hi!

  Is there a way to trap errors when running mactro?  For example, if a
macro is called to perform a data step including a "merge by" statement
and the dataset included is not properly sorted, there will be an error
and cause SAS to stop proceeding.  Can the calling code trap this error
code?  Some applications use return codes for instances like this for
calling code to take appropriate action.  Is there a similar return code
in SAS?  If so, usually how is it handled in the calling code?

  TIA

  J S Huang

4. Trapping FTP codes

5. Trapping XML errors

We are reading from XML files (XML libref) into SAS data sets. If there is
an error in the XML (for example, a missing end tag), we want to be able to
trap this error. We can use a DATA step, PROC COPY or PROC SQL to read from
the XML libref into a SAS data set. However, even though there is an ERROR:
message in the log window, SAS does not set the SYSERR (or SQLRC) macro
variables after the DATA or PROC step finishes.

Our only solution at this point is to redirect the log to a file right
before the DATA or PROC step that reads the XML into a data set, then parse
the log file, looking for "ERROR:". This is a pretty un-elegant solution.
Is there a better way to handle this?

Thanks in advance for all answers.

6. Trapping File Name

7. Error Trapping?

As part of a report we are making a large number of graphs.  If for some
reason no data is available for a particular client SAS graph does not
produce the graph. Is there someway to trap this error so that we can
handle the loss of the graph? Is there a macro variable set on error?

Steve Bittner

8. Speed Traps - A useful site ?