Date:         Wed, 16 Dec 2009 13:49:33 -0500
Reply-To:     Michael Raithel <michaelraithel@WESTAT.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Michael Raithel <michaelraithel@WESTAT.COM>
Subject:      Re: "write access denied" message
In-Reply-To:  <54E01EE17F635448A5CE0C2253E23FF90195C405@CONSTANCE.DOH.OK>
Content-Type: text/plain; charset="us-ascii"

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@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
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++