10-11-2013 10:09 AM
Hi SAS Coder,
Scenario of problem - I have one macro say %callme . this macro is called in one sas code say useme.sas . Now I have many SAS jobs which executes useme.sas code based on some parameters. so at a given time many SAS jobs execute useme.sas which inturn has many calls for macro %callme;
macro callme logs some details to one SAS dataset (logging.sas7bdat)like username, time of call etc... now when many sas jobs execute and call macro CALLME ; then sometimes I get this error "ERROR: The open failed because library member Library.LOGGING.DATA is damaged." . Although I have filelocks option in my SAS code I still get this error.
Strange thing is that dataset LOGGINGis not damaged and I can open it easily; there is no space issues. and once I rerun my code one by one problem does not appear.
only when there is simultaneous update to dataset LOGGING I get this problem (this is my observation , there could be any other thing which caused this.)
Can any one help me in solving this or point to the cause??
10-11-2013 10:50 AM
I assume from your description that the macro writes this information to common table (Logging.Data is the same for all calling SAS programs).
I'm not sure about this specific error, but the single user Base SAS engine does not handle concurrent read/write requests on a record level. To make your writes/updates consistent you need any the following:
10-14-2013 10:31 AM
thanks for your reply . but how to know that my BASE SAS engine is 'single user Base SAS engine' . because I can perform simultaneous read from a SAS dataset(some other XYZ dataset) but when it comes to write to the same dataset by same user but in different sessions then I get the problem.
I thought option filelock will allow it to write to the dataset but apparently it did help in getting the problem solved.
If there is no way to handle this with some options then probably RDBMS table is only solution.
10-14-2013 10:35 AM
Base is per default a single user engine, but it allows for simultaneous read operations. But as soon there is any kind of write/delete/update operation, the whole table is locked for other users, or if there is already a read lock, the update operation will fail.
If %callme is the only client you may add some lock checking within that macro, if not the requires lock is available then insert a wait, and try again. Quite manual, but can work for some applications.