Chapter Contents

Previous

Next
Moving and Accessing SAS Files across Operating Environments

Role of the SAS/SHARE Server in a Client/Server Session

Here is a simple example of how a SAS/SHARE server manages multi-user access to a common data set.

  1. Following the setup of a pathway to the server SHR1, client USER1 on a Windows host creates a data set named TERM1 in the server-defined library RECORDS:
    data records.term1;
      input student $ test1 test2 final;
      datalines;
    Barney 80 74 88
    Betty 98 89 92
    ;
    proc print data=records.term1;
     run;

  2. USER2 on a CMS host starts another SAS session in order to edit the data set TERM1 in the server-defined library RECORDS. Here is typical SAS code:
    options comamid=tcp;
    libname records server=rmtnode.shr1;
    proc fsedit data=records.term1;
    run;
    This example declares the TCP/IP communications access method as the pathway between the server SHR1 and the client USER2. The pre-defined server library RECORDS is accessed by means of the server SHR1 that is located on the UNIX host RMTNODE. The FSEDIT procedure accesses the first observation in the data set that USER1 created. The server SHR1 locks the first observation in the data set to USER2. USER2 then changes a grade in the first observation.

  3. USER1 also attempts to edit the first observation in the data set TERM1 by using these statements:
    proc fsedit data=records.term1;
    run;
    Because the server locked the first observation in the data set for USER2's FSEDIT session, USER1 cannot gain access to that observation for update. Only after USER2 saves the change and moves to the next observation or exits the FSEDIT session, does the server release the lock, which permits USER1 to update the first observation.


Chapter Contents

Previous

Next

Top of Page

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