"write access denied" message
in [SAS]
|
Prev: REGULAR EXPRESSIONS
Next: variance component model
From: "White, Svend A." on 16 Dec 2009 16:54 Thank you, Michael, for taking the time to offer such comprehensive and enlightening suggestions. 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. Thanks. Svend > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of > Michael Raithel > Sent: Wednesday, December 16, 2009 12:50 PM > To: SAS-L(a)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 > depending > > on the options selected by the user. There are 4 scenarios (i.e., > user > > choice combinations), but only one of them is working. The other > three > > 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. > This > > 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, and > 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", like > "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 data > sets that you can update. > > 7. You might also want to experiment and see if you can simply read one > 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 into > the root causes of this vexing problem. Because, you know that it will > 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 so > at their own risk. > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Michael A. Raithel > "The man who wrote the book on performance" > E-mail: MichaelRaithel(a)westat.com > > Author: Tuning SAS Applications in the MVS Environment > > Author: Tuning SAS Applications in the OS/390 and z/OS Environments, > Second Edition > http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58172 > > Author: The Complete Guide to SAS Indexes > http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60409 > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > The only trouble with problems that go away on their own is that > They tend to come back on their own. - Anonymous > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |