BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
MattDSS
Fluorite | Level 6

Compiled SAS macro libraries cannot be updated/overwritten while they are being read by one user. If I try to compile a macro while it is being read, I would get an error saying that "A lock is not available for LIBRARY.SASMACR"

If one of our user launched the library, but forgot to the turn it off before taking 3 days leave, then I can't change it for the next 3 days!

Is there anyway to override this and to give me privileges to the library?

1 ACCEPTED SOLUTION

Accepted Solutions
SASKiwi
PROC Star

To avoid this problem in the future you could re-design your use of compiled macros so each read-only user copies LIBRARY.SASMACR to their WORK directory and uses macros from there. Alternatively don't use pre-compiled macros, use AUTOCALL macros instead which get compiled on the fly to each user's WORK library. We use the latter approach and it avoids locking issues entirely.  

View solution in original post

18 REPLIES 18
ballardw
Super User

Sounds like an IT sys admin question to log them off of a process.

sbb
Lapis Lazuli | Level 10 sbb
Lapis Lazuli | Level 10

Cancel the user's session and tell the individual not to do it again - such serialization for any SAS OBJECT library is critical for successful operation.

SASKiwi
PROC Star

To avoid this problem in the future you could re-design your use of compiled macros so each read-only user copies LIBRARY.SASMACR to their WORK directory and uses macros from there. Alternatively don't use pre-compiled macros, use AUTOCALL macros instead which get compiled on the fly to each user's WORK library. We use the latter approach and it avoids locking issues entirely.  

jakarman
Barite | Level 11

The reason the read lock is needed is because of possible inconsistency when those compiled versions would change on the fly.  That is a common logical situation happening in many more situations.

No, you cannot overwrite that protection.

The options:

Your release management process should have some Sla of time moments the updates could be done and allowing you to kill all blocking processes.

Work with local copies Eg a sas_work version for the persons doing too many updates (developers).

---->-- ja karman --<-----
MattDSS
Fluorite | Level 6

Thanks for the suggestions everyone. So the answer is no. It would be good, in future SAS, to allow compilers of the macro to add a password or something that would give them privileges to the library.

For now, I can try the auto-call suggestion.

jakarman
Barite | Level 11

If you would think the fundamental logical problem  behind locking is an Sas issue you are wrong go and look what is in acid with a rdbms system.  That question of locking on artifacts that are getting updated is a  generic one.

The Autocad is avoiding that question as the resulted compiled version is sa local one.

---->-- ja karman --<-----
MattDSS
Fluorite | Level 6

Thanks for pointing the ACID thing.

I don't think it is a fundamental logical problem. I do think, though, that putting an special password on a file which would allow overwrite privileges to be a good idea.

sbb
Lapis Lazuli | Level 10 sbb
Lapis Lazuli | Level 10

Any SAS OBJECT library would typically have similar "authorized" replacement consideration, whether it is a compiled-MACRO library, a SAS DATA library or a SAS FORMAT member.

It's imperative that rules/procedures be adopted to manage these environments, especially inadvertent or others undesired library "locking" situations.

Scott Barry

SBBWorks, Inc.

Kurt_Bremser
Super User

It is not a question of passwords etc. No operating system allows rewriting a complete file when a process has an open file handle on it. Only when certain random access modes are used can parts of files be updated while other processes also have access to the file.

A SAS catalog does not have a structure that lends itself easily to random access read/writes, so it is always rewritten completely.

So it is technically not possible to do what you want, at least not with justifiable effort.

jakarman
Barite | Level 11

That ACID thing is coming from F.Codd father of SQL and got many rewards for that. The whole theory behind that is a logical one of who wants to update a object who are using that at the moment an how resolving those request conflicts.

As a logical process it is not solvable by means of some password. If our great awarded leaders came with this all supported by mathematics why wouldn't it be true. When you are convinced of that than your underpinning should be of same quality as they did.

---->-- ja karman --<-----
MattDSS
Fluorite | Level 6

I think there is some misunderstanding about what I want with a "password". I do not want to write while others are reading - I understand this is not possible. Instead, I want to be able to abort users who are using my library.

Isn't it simple? If I enter a password when using my library, instead of returning "A lock is not available for LIBRARY" to me, it will return "Your program has been aborted because user X has taken control of LIBRARY." to whoever is occupying the catalog. Surely the IT admin can abort users. The question is whether this sort of abilities can be given to normal users.

On that note, I don't even know how users can disconnect THEMSELVES from the library. Whenever I tell my colleagues to return control of the library to me, nothing they try could work - setting nomstore, or clearing the libname. The only way for them to return control is to disconnect their profile. This is really inconvenient because they lose whatever they are working on.

Is there anyway they can disconnect themselves from the library? Or is there some fundamental reason in SAS that would prohibit this?

Patrick
Opal | Level 21

This is about a stable environment. If you would "abort users" then this is the same than users closing their sessions - they will loose their environment. If you have admin rights then you can kill sessions of other users - but it's quite "brutal". You can also simply re-start the object spawner which will end all sessions (except for batch processes).

What's the reason that you have to pre-compile macros? That's something I would only do in a serious production environment where you have proper release management - and then it's no problem as during the few release windows a year you can inform users that the server will be down so you won't have locking issues.

If this is more of an "adhoc reporting" environment where you're maintaining the "SAS framework" then I don't see any reason why you can't use the Autocall facility where you store macros as .sas files which then will get compiled and copied into the users work library once they first call the macro. Such an approach doesn't make any difference to users but you will never have locking issues.

MattDSS
Fluorite | Level 6

Aborting programs is different from aborting sessions right? A %abort, for example, doesn't cause users to lose their environment.

I am, actually, in the environment you are talking about. I could use the autocall, or I could, like SASkiwi suggests, get users to copy the library.  This would work too.

Sorry for all the dumb questions! I am a newbie to SAS. I did some C++ when I did my doctorate in mathematics, but I only wrote for myself and didn't have these issues I am facing now.

Patrick
Opal | Level 21

Not really. During SAS invocation the environment gets established - the work library, SAS macro variables etc. etc.  That's the same for a batch process than for a session.


So if you use SAS EG for example and you connect to a SAS Server a new SAS session gets "spawned" (using the SAS Object spawner). That's when all the config files and autoexec's get executed. If you end the session (or a batch process) using %abort then the session/process ends and you loose the environment (like the work space) - in a Windows environment you would see a sas.exe task terminate.


If you want to get a better understanding of how SAS works then I strongly recommend you read the SAS Concepts manual http://support.sas.com/documentation/cdl/en/lrcon/67885/PDF/default/lrcon.pdf (it's a very good and well written manual).

For your case: I strongly recommend you don't pre-compile macros but store them simply as .sas file in a folder which is part of the macro search path SAS(R) 9.4 Macro Language: Reference, Third Edition

You simply store your SAS macros in .sas files which have the name of the SAS macro (in UNIX: name must be all in lower case!). The folder location where you store these macros must be defined in SASAUTOS (that's simply the definition of a search path for macros).

When users call a macro then SAS will search for a .sas file in the macro search path (SASAUTOS). Part of this search path is Out of the box - and it can be an actual physical path or a catalog in a library. One of the first places where SAS looks for a macro is in the WORK library (for members in catalog SASMACR).

Sooo... You have your .sas file with the name of the macro stored in a folder which has been defined in SASAUTOS. The first time the user calls the macro in the code SAS will scan through the macro search path, find this .sas file, compile it, and store it in the macro catalog in WORK.

The second time the user calls the macro (in the same SAS session) SAS will again scan through the macro catalog. But it looks first in WORK, now finds the compiled macro there and will use this one (...so if you changed in-between the macro code in the .sas file the user will still get the old version).

Using SAS EG if the user disconnects from the Server the work-space gets cleaned out. When he re-connects a new work space gets created. So now if the user runs code calling the macro then SAS will again scan through the macro search path, there won't be a compiled macro in WORK so it will find it the first time as .sas file in the folder which is part of the search path... and the story starts from the beginning.

It's very long ago that I've done something with C++. Working with SAS is very different. Forget about compilation. With SAS it's all done "on the fly" during run-time. There are only a few exception to this - and as I understand the environment you're in you won't have to care about these exceptions. So: Don't care about compilation at all.

...Hope this made it clearer to you. Read the Concepts Manual - it's all in there and much much more - and it's may-be the most important SAS manual to be read if you want to get a deeper understanding of how SAS works.

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 18 replies
  • 5119 views
  • 5 likes
  • 8 in conversation