Date: Wed, 16 Dec 2009 15:54:40 -0600
Reply-To: "White, Svend A." <SvendW@HEALTH.OK.GOV>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "White, Svend A." <SvendW@HEALTH.OK.GOV>
Subject: Re: "write access denied" message
Content-Type: TEXT/plain; charset="us-ascii"
Thank you, Michael, for taking the time to offer such comprehensive and
I look forward to trying them out when I get back to that project
shortly--I'm sidetracked on a more imminent deadline at the moment--and
will share the resolution with the list when I'm done.
> -----Original Message-----
> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
> Michael Raithel
> Sent: Wednesday, December 16, 2009 12:50 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: "write access denied" message
> Dear SAS-L-ers,
> One week ago to the day, Svend A. White posted the following:
> > I'm a SAS newbie with a report that needs to create a dataset
> > on the options selected by the user. There are 4 scenarios (i.e.,
> > choice combinations), but only one of them is working. The other
> > throw an error like this:
> > "ERROR: Write access to member DEVDATA3.SURG_07.DATA is denied.
> > NOTE: The SAS System stopped processing this step because of errors.
> > NOTE: SAS set option OBS=0 and will continue to check statements.
> > may cause NOTE: No observations in data set.
> > NOTE: PROCEDURE SORT used (Total process time):
> > real time 0.01 seconds
> > cpu time 0.01 seconds"
> > I've tested the code separately and all 4 of the following code
> > snippets
> > work fine from the command line:
> > #1 (works) proc sort data=surg.surg_06; by UID; run;
> > data uid06;
> > set surg.surg_06; by UID;
> > if first.UID; run;
> > #2 proc sort data=surg.surg_07; by UID; run;
> > data uid07;
> > set surg.surg_07; by UID;
> > if first.UID; run;
> > #3proc sort data=surg.surg_06; by pk_event; run;
> > data pk06;
> > set surg.surg_06; by pk_event;
> > if first.pk_event; run;
> > #4 proc sort data=surg.surg_07; by pk_event; run;
> > data pk07;
> > set surg.surg_07; by pk_event;
> > if first.pk_event; run;
> > If one works, shouldn't they all?
> Svend, I see that Dan and Charles both svent you some great advice,
> I see that by last Friday, you had a workaround. Good deal; you got
> over the hump on this issue!
> But, it must be less than satisfying to have a workaround instead of a
> solution. So, here are some thoughts that may, or may not, overlap
> some of the ideas put forth by aforementioned esteemed SAS-L-ers, but
> are designed to see if you can overcome this problem.
> 1. Make sure that you don't already have the data set open in a SAS
> Display Manager session. Also make sure that somebody else doesn't
> have the data set open for update.
> 2. Make sure that you do not have the NOREPLACE system option in
> effect. <--Not likely in your case.
> 3. Make sure that you do not have the ACCESS=READONLY option in effect
> for the SAS data library. <--Not likely in your case.
> 4. See if some sneaky somebody has password protected the data set
> using SAS. Execute a PROC CONTENTS on the offending SAS data sets and
> look for the value of "Protection" in the Attributes (1st ) section of
> the CONTENTS output. Is it blank, or does it specify something like
> READ, WRITE, or ALTER?
> 5. If your offending SAS data sets are on UNIX or Linux, run PROC
> CONTENTS and see what the "Access Permission" field reads like in the
> "Engine/Host Dependent Information" (2nd) section of the CONTENTS
> output. If will have the usual UNIX/Linux permission "mode bits",
> "rw-rw-rw- ". Are they consistent with allowing Y-O-U access to the
> SAS data sets?
> 6. Ask a friendly Systems Programmer to check out the offending SAS
> data sets on the server and ask her to determine what is different
> about the permissions specified on them, versus permissions on the
> sets that you can update.
> 7. You might also want to experiment and see if you can simply read
> or more of the offending SAS data sets. We know you cannot update
> them, but what about simply reading them?
> Svend, hopefully one or more of these routes will give you insight
> the root causes of this vexing problem. Because, you know that it
> rear its ugly head when you both least expect it and can least afford
> for it to happen.
> Svend, best of luck in all of your SAS endeavors!
> I hope that this suggestion proves helpful now, and in the future!
> Of course, all of these opinions and insights are my own, and do not
> reflect those of my organization or my associates. All SAS code and/or
> methodologies specified in this posting are for illustrative purposes
> only and no warranty is stated or implied as to their accuracy or
> applicability. People deciding to use information in this posting do
> at their own risk.
> Michael A. Raithel
> "The man who wrote the book on performance"
> E-mail: MichaelRaithel@westat.com
> Author: Tuning SAS Applications in the MVS Environment
> Author: Tuning SAS Applications in the OS/390 and z/OS Environments,
> Second Edition
> Author: The Complete Guide to SAS Indexes
> The only trouble with problems that go away on their own is that
> They tend to come back on their own. - Anonymous