Date:         Mon, 25 Nov 2002 15:42:24 -0600
Reply-To:     "Suzanne D. McCoy" <smccoy@LUCIDAN.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
Comments:     To: JBosch1@PRDUS.JNJ.COM
From:         "Suzanne D. McCoy" <smccoy@LUCIDAN.COM>
Subject:      Re: SAS/UNIX Work Area
In-Reply-To:  <73FC8D4DCAD8D41190B300508B6980C202DFB50B@RARUSRAEXS13.prius.jnj.com>
Content-Type: text/plain; charset=iso-8859-1

Jules,

I would start with the Oracle tables.  Is anything different there like
maybe integrity constraints?  I'd have to see the code to give any more
suggestions.

Suzanne
--
Suzanne D. McCoy
Lucid Analytics Corp.
"Intelligence Unleashed"

> Dear All,
>
> We ran some SAS (V8.2) application tests on Nov 14 in a UNIX test
> directory. We purposely created  bogus records to force the tests to
> fail and they did. When the application fails the SAS process stops and
> locked ORACLE tables remain locked and no update is attempted.  This is
> good.
>
> On Friday Nov 22, the processing of our SAS application was directed to
> another UNIX work area on the same server.  Now, however, the bogus
> records do not force errors, as they did on Nov 14, and the ORACLE
> tables are unlocked and overlaid with bogus data.  This is bad.  Of
> course, the SAS code in play has not changed since Nov 14.
>
> So, is it possible that the second SAS work area could be different in
> some way from the original SAS work area such that the described
> untoward behavior could occur?  I can't think of any other change that
> has taken place that would cause this problem.
>
> Any thoughts would be greatly appreciated.
>
> Jules Bosch