Hi, Michael

Thanks so much for that tip. Fortunately, it seems that the error went away during the night. Now, several reports are each pulling 2 such shared macros without incident, so I guess the process automatically releases the catalog eventually.

Even if that's the case, I imagine I'll still need to do that restart when deploying shared macros to a public-facing server. Also, if this happens with an internal testing server that isn't used by many users and if server load plays any role I imagine the catalog might be frozen for even longer on a public server, so a restart would be essential.

Thanks.

Svend

> -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L@listserv.uga.edu] On Behalf Of > Michael Raithel > Sent: Wednesday, June 15, 2011 7:22 AM > To: SAS-L@listserv.uga.edu > Subject: Re: problems with locks on stored macros > > Dear SAS-L-ers, > > Svend posted the following: > > > I'm trying to set up some macros that will be shared by a dozen > reports > > on SAS/IntrNet. > > > > A few minutes ago, it seemed like I was home free, as I had several > > reports invoking the same macro. Now, without making any changes (the > > only thing I did was compile and save a second macro to the same > > location), I'm getting this error: > > > > ERROR: A lock is not available for DVMACROS.SASMACR.CATALOG, lock > held > > by another process. > > ERROR: A lock is not available for DVMACROS.SASMACR.CATALOG, lock > held > > by another process. > > ERROR: The SAS System was unable to open the macro library referenced > > by > > the SASMSTORE = libref DVMACROS. > > WARNING: Apparent invocation of macro DUMMY_REPORT not resolved. > > > > Any idea why this might be happening? > > > Svend, maybe the SAS/IntrNet appserver is the "other process" that has > the catalog locked. I would bet that the appstart.sas program for your > application allocates that catalog and hence it is tightly held by your > appserver. Try this: > > 1. Stop your appserver. > 2. Compile your macros. > 3. Restart your appserver. > > That might do the trick! If not, let us know and we can go to Plan > B... whatever that is:-( > > Svend, best of luck in all 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 > > SAS Press Author Page: > http://support.sas.com/publishing/authors/raithel.html > > 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 > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > A person who won't read has no advantage over one who can't read. - > Mark Twain > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++