Chapter Contents
Previous
Next
SAS/SHARE User's Guide

How Implicit Locking Works in SAS Program Steps

The following example shows the effect of implicit locking when two clients, John and Maria, share access to the SAS data set FUEL in their respective PROC FSEDIT sessions at the same time. Maria is updating observation 6.

John terminates his FSEDIT session to do some data analysis. He wants a sorted report of fuel inventory data, so he submits statements to sort and print the data set FUEL. Attempt to Sort a Locked Data Set shows the SAS log for this portion of John's session:

Attempt to Sort a Locked Data Set
   Command ===>

   3   PROC SORT DATA=DATALIB.FUEL;
   4   BY AREA;
   5   RUN;

   ERROR: You cannot open DATALIB.FUEL.DATA for output access
          with member-level control because DATALIB.FUEL.DATA
          is in use by FSEDIT.
   NOTE: The SAS System stopped processing this step because 
         of errors.
   NOTE: The PROCEDURE SORT used 0.03 CPU seconds and 3969K.

   6   PROC PRINT DATA=DATALIB.FUEL;
   7   BY AREA;
   8   RUN;

   ERROR: Data Set DATALIB.FUEL is not sorted in ascending 
          sequence. The current by-group has AREA = TEX1 
          and the next by-group has AREA = TEX2.
   NOTE: The SAS System stopped processing this step because 
         of errors.
   NOTE: The PROCEDURE PRINT used 0.03 CPU seconds and 4068K.

For details about error message formats, see Locking Message Format.

Because the OUT= option is not specified in the PROC SORT statement, the process defaults to the data set named by the DATA= option and the SORT procedure tries to replace the SAS data set. However, because Maria's FSEDIT session has the data set open for update, the SORT procedure cannot open it for output.

The SAS log shows that the PROC PRINT step executes because the PRINT procedure opens its input data set with observation-level control. However, the PRINT procedure terminates prematurely because the data set is not sorted properly. Note that even if the data set were in sorted order when John terminated PROC FSEDIT, Maria could have changed the value of AREA in one or more observations so that the data set would no longer be sorted properly when the PRINT procedure executed.

To avoid the conflict and ensure that he gets the report he wants, John can use the OUT= option to write a copy of the sorted data set into his WORK library, as shown in the following example: 

proc sort data=datalib.fuel out=fuel;
   by area;
run;

John avoids a conflict because this PROC SORT statement opens the data set DATALIB.FUEL only for input with observation-level control.

John can then use the PRINT procedure to display the temporary data set WORK.FUEL.


Chapter Contents
Previous
Next
Top of Page

Copyright 1999 by SAS Institute Inc., Cary, NC, USA. All rights reserved.