Since SAS does not handle locks on tables in separate SAS sessions inherently (see SAS Lock documentation), Risk Stratum Core provides its own code to prevent locking issues when multiple users are trying to access the same tables. This code involves an entry in the RMCDR.MASTER_SEMPAHORE table and the creation of mutex files on the file system. If a job quits unexpectedly (such as due to a server restart, environment issue, and so on) while a lock had been reserved on a resource, those master_semaphore entries and/or mutex files might become orphaned and prevent future processes from acquiring a lock on the given resource. In this scenario, the following error appears in your SAS log.

Solution

Navigate to your SASRiskWorkGroup directory and then open the groups/Public/SASRiskManagementCore folder. Within that folder, delete any old mutex files. In SAS^® Studio or any other SAS client, remove all old entries from the RMCDR.MASTER_SEMAPHORE table.

Additional background information:

• The MASTER_SEMAPHORE entry and mutex file are created in the irm_acquire_lock macro. If you want to see the details about how this file is created, you can look at the code for this macro (<RSC content>/irm/source/sas/ucmacros). If you want to see how this macro is used, you can grep for irm_acquire_lock in the RSC directory and your solution's directory (or use a file search tool like FileLocator if you are not familiar with grep).
• An "old" master_semaphore entry or mutex file is one that is no longer relevant. If you know there are no processes running on the resource to which the master_semaphore entry or mutex file corresponds, then you know that the entry/file is old and can be deleted safely. Both the master_sempahore entry and mutex file contain information about the resource being locked, the process id, and the process datetime. This is described further below. The resource name/id is the resource passed to the irm_acquire_lock macro. If you want to confirm that the master_semaphore entry or mutex file can be safely deleted, you can check whether the process id is still running. If the pid does not exist, then the master_semaphore entry and mutex file can be deleted safely.
• The MASTER_SEMAPHORE table (as shown below) contains columns for the resource_id (the resource name passed to the irm_acquire_lock macro), the process id, the priority, and the processed datetime:
  
  

 

• The mutex file is always named <lowcase(resource_name)>.mutex and the contents of the file include the date, time, and pid of the process that created it.
• To provide an example, in RSC v10.2020, the irm_upload_to_lasr macro calls irm_acquire_lock on resource RMCLASR.&target_table_nm. If you run irm_upload_lasr for RMC_DQ_SUMMARY, then you would expect to see an entry in the RMCDR.MASTER_SEMAPHORE table with resource_id of "RMCLASR.RMC_DQ_SUMMARY", a pid corresponding to the process (such as pid = 11403) and a process_dttm of the process (such as 09FEB2021:13:45:52.169). Once that entry is added, you would expect to see a mutex file called rmclasr.rmc_dq_summary.mutex created. The contents of this file would include the process information. Here is an example: 2021.02.09 13:45:52 - Process Id: 11403. Once this file is created, that master_semaphore entry would be deleted.
  • If the job was killed while acquiring the lock, the master_semaphore table might include the entry for this process (if the job was killed before the entry could be deleted after acquiring the lock). In this case, this entry would need to be removed before any other process can acquire a lock on the specified resource. If the job was killed after the mutex file was created, then this mutex file will similarly be "orphaned" as it is no longer tied to an existing process. You would need to manually delete this mutex file before any other process can acquire a lock on the specified resource.