From: Sigurd Hermansen on
Raj:
A simple contention for write access to a dataset (WORK or otherwise)
occurs whenever one user process is reading a dataset and another user
process attempts to write to a dataset with the same name. Unless
processes always use distinct dataset names, a WORK.X sort writing to
name WORK.X will fail with a runtime rename error when it attempts to
rename temporary file(s) WORK.X. Failures to clean up orphan WORK
datasets following run-time errors may cause more errors.

I'd look at the potential for contention between write and read
processes as a first step. Enterprise Guide may have configuration
options that will give WORK datasets names specific to a user, process,
or datetime stamp. Seems that it should. Good programming practice
requires different names for source and destination files for sort
operations and disjoint sets of names for processes that might happen,
even rarely, to generate a name conflict.
S

-----Original Message-----
From: owner-sas-l(a)listserv.uga.edu [mailto:owner-sas-l(a)listserv.uga.edu]
On Behalf Of Raj
Sent: Thursday, November 08, 2007 3:04 PM
To: SAS-L(a)LISTSERV.UGA.EDU
Subject: Rename of Temporary Member Failed


Dear SAS Users,

At our company, we have been running into this strange error where SAS
programs intermittently fail with the message "ERROR: Rename of
temporary member for WORK.XXXX failed.". Sometimes, this error message
is accompanied by another error "ERROR: User does not have appropriate
authorization level for file WORK.XXXX". This error could happen when
the dataset is being sorted using a SORT procedure without OUT= option,
updated using a SET statement, or when being created for the first time
by reading in a flat file.

We have been contacting SAS tech suppot over the last few days, but
there hasn't been any progress so far. They made us try different things
like, making sure the users have read/write access to the specified
folders, enough disk space for SAS to write datasets, uninstalling
anti-virus, uninstalling data replication software, uncompressing our
drives on the server, etc. We also implemented a Microsoft KB solution
when a Read-Only attribute cannot be removed for a folder (KB# 256614).

The problem is intermittent and is happening with several different
programs. Each time, a program could break at a differnt line in the
code. We noticed that the problem goes away if we reboot the server,
only to reappear after few days. And if it occurs once, it starts to get
worse and occurs more frequently.

We use Enterprise Guide in our company where several users (upto 10) run
multiple sessions on the Server simultaneously. So I was wondering if it
could be the case of some resource running short. That's why a reboot
might be clearing things up for few days.

There have been few posts on this error in the past but I couldn't find
a solution yet.

Any suggestion is highly appreciated.

Thanks,
Raj