Date:         Mon, 24 Jun 2002 12:50:58 -0400
Reply-To:     Ed Heaton <EdHeaton@WESTAT.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Ed Heaton <EdHeaton@WESTAT.COM>
Subject:      Re: Caution when using the RETAIN statement??!
Comments: To: "Simon.Gillow@BBG.CO.UK" <Simon.Gillow@BBG.CO.UK>
Content-Type: text/plain; charset="iso-8859-1"

Simon,

The problem is that you are using RETAIN for more than ordering the data set
variables.  You can safely use RETAIN for ordering variables from the SET
data set, however you are adding another variable called CHECK which did not
exist in the SET data set.

In the case mentioned, you used the RETAIN statement to put the CHECK
variable at the end of the data set.  This is where it would be if you did
not include it in your retain statement.

Okay, suppose you wanted CHECK to be the first variable.  Then you might
want to include CHECK in the RETAIN statement as follows:

        Retain check level1-level3 ;

Now you have the problem.  However, the problem is with the assignment part
of the DATA step, not the RETAIN statement.  Try,

        Select (level2) ;
           When ("TOKYO" ) check = "Tokyo"  ;
           When ("LONDON") check = "London" ;
           Otherwise       check = " " ;
        End ;

The advantage of the select statement is that it forces us to consider every
option.  Sure, I could code

        Otherwise ;

but then I would have to purposely, rather than inadvertently, shoot myself
in the foot.

So, yes, the RETAIN statement can get us in trouble.  More likely, it
exacerbates the effects of troublesome code.  A good creed is to always
assign values to variables and never allow SAS to plug in it's default
missing value.  For numeric variables, I try to always assign one of the
"other" missing values.  That way, a dot is always cause for alarm.

Ed


Ed Heaton
#4818
TA-2018


-----Original Message-----
From: Simon Gillow [mailto:Simon.Gillow@BBG.CO.UK]
Sent: Monday, June 24, 2002 11:54 AM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Caution when using the RETAIN statement??!


Hello all,

We often use the RETAIN statement to change the ordering of variables in a
SAS dataset.

It was found that when using a RETAIN statement that if you are using an IF
condition to create/alter the contents of a variable that you need to code
specifically for every eventuality. This is best explained with an example.

The dataset SASHELP.COMPANY contains a variable called level2 which has 3
possible values, TOKYO, LONDON or NEW YORK. This dataset is used in the
following examples.


When I run the following data step:

data company_error;
   retain level1 level2 level3 check;
     set sashelp.company (keep=level1 level2 level3);
     if level2='TOKYO' then check='Tokyo';
     else if level2='LONDON' then check='London';
run;

With this coding you would expect check to either contain 'Tokyo', 'London'
or be blank,but that isn't the case!

You will notice that the population of the check variable is correct when
level2 is either TOKYO or LONDON but it still shows 'Tokyo' for NEW YORK,
this is because the RETAIN statement has retained the previous value for
check because NEW YORK wasnt specifically coded for.

Now when I run:

data company_no_error;
   retain level1 level2 level3 check;
     set sashelp.company (keep=level1 level2 level3);
     if level2='TOKYO' then check='Tokyo';
     else if level2='LONDON' then check='London';
     else check=' ';    /*NOTE This line is needed to mop up any instances
that arent covered specifically*/
run;

This time the check variable is populated as we would expect.

Can anyone suggest why this happened? Are there any other pitfalls involved
with the use of RETAIN?

Thanks,

Simon



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.


Bradford & Bingley plc
Registered Office: PO Box 88, Croft Road, Crossflatts, Bingley, West
Yorkshire, BD16 2UA
Registered in England No. 3938288
Regulated by the Financial Services Authority and a Member of the General
Insurance Standards Council.

http://www.bbg.co.uk
Bradford Bingley plc
**********************************************************************