Date: Thu, 29 Aug 2002 15:56:27 -0400
Reply-To: "Dorfman, Paul" <Paul.Dorfman@BCBSFL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Dorfman, Paul" <Paul.Dorfman@BCBSFL.COM>
Subject: Re: Version 6.09 to 8.2 conversion
Content-Type: text/plain; charset=iso-8859-1
David,
Very well! Your reply has induced me to recall that during a conversion,
close attention should be paid to SAS programs communicating with DB2 (since
it is MVS). Namely, because in V6, no names longer than 8 characters were
allowed, if a query send to the database via the Pass-Thru did not use
aliases to create SAS variable names, but instead left it to SAS to concoct
its own names from DB2 column names by chopping them off and mainpulating
their suffixes (which I have never done myself but seen other people do it
in plenitude), and subsequent step(s) used these SAS-concocted names, then
in V8, the same program the program will bomb. Reason: since in V8, allowed
variable names are actually longer than those in DB2, in the above
situation, the DB2 column names would migrate to SAS intact, and it may not
be the name referenced by the V6 program earlier.
Example: Suppose a DB2 table has a column called MESTRATEGY. If in a V6
pass-thru query, I, exhibiting a bad coding practice, coded
proc sql ;
connect to db2 (ssid=wxyz) ;
create table WARPLAN
select * from connection to db2 (
select MESTRATEGY
from MEWAR.PENTA_COMP
where BAD_GUYS = 'DEAD'
and GOOD_GUYS NOT= 'DEAD'
) ;
quit ;
(instead of coding
select MESTRATEGY as MESTRATE
), then in V6, SAS would chop MESTRATEGY to MESTRATE. If, knowing that, I
further coded
Proc Print data = warplan ;
Var MESTRATE ;
run ;
that would work fine as long as it run under V6. But in V8, SAS will not
chop anything off, and the DB2 column MESTRATEGY will quietly become a
variable MESTRATEGY in the SAS data set WARPLAN. Proc Print will then bomb
upon not finding the variable MESTRATE to print.
A right remedy would be to leave the SQL intact and change all the
subsequent MESTRATE references to MESTRATEGY. However, in a large
organization a variable name can have been proliferated to the point where
fixing the situation this way may not be feasible. Then there is nothing to
do but to code the previously forgotten
select MESTRATEGY as MESTRATE
into the SQL query. The whole point is, during a V6-to-V8 migration, all
DB2-related SAS programs deserve a close look, unless one enjoys production
surprises and time bombs (making production support less boring, I guess).
Kind regards,
==================
Paul M. Dorfman
Jacksonville, FL
==================
> -----Original Message-----
> From: David L. Cassell [mailto:Cassell.David@EPAMAIL.EPA.GOV]
> Sent: Thursday, August 29, 2002 1:08 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: Version 6.09 to 8.2 conversion
>
>
> "Dorfman, Paul" <Paul.Dorfman@BCBSFL.COM> replied, with his usual
> masterful discussion,
> and then added:
> > 4) I may have omitted something important - which other folks, I am
> sure,
> > will catch and fill in the gaps.
>
> Not much else, but the poster really should run through a series of
> standard programs to ensure that nothing breaks. There has
> been plenty
> of discussion on small details of macro processing and such
> that differ.
> Some of these matter to some programs. I have a 70K sampling program
> which needed *no* alteration whatsoever when moving from 6.12 to 8.1 .
> But we also had a small program which choked because the name of the
> intercept variable in PROC REG output switched from 'intercep' to
> 'Intercept'.
>
> David
> --
> David Cassell, CSC
> Cassell.David@epa.gov
> Senior computing specialist
> mathematical statistician
>
Blue Cross Blue Shield of Florida, Inc., and its subsidiary and
affiliate companies are not responsible for errors or omissions in this e-mail message. Any personal comments made in this e-mail do not reflect the views of Blue Cross Blue Shield of Florida, Inc.
| 
