From: Sigurd Hermansen on 9 Nov 2007 14:05 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
|
Pages: 1 Prev: Proc TABULATE, mixed up on missing Next: Convert Datetime data from ASCII code to SAS Datetime |