SHARING SAS DATA INA PC LAN ENVIRONMENT. Tony Payne, SPS Ltd. ABSTRACT

Size: px

Start display at page:

Download "SHARING SAS DATA INA PC LAN ENVIRONMENT. Tony Payne, SPS Ltd. ABSTRACT"

Beverly Greer
5 years ago
Views:

1 I I SHARING SAS DATA INA PC LAN ENVIRONMENT Tony Payne, SPS Ltd. ABSTRACT F ' The SASe System, version 6.03 and beyond, provides powerful control of data editing sessions using the FSEDIT procedure with Screen Control Language (SCL). With more and more operating environments allowing concurrent access to data, the problem of controlling shared access needs to be addressed. The SAS Institute are providing SAS/SHARE software to address these issues, but this is not yet available on all platforms. This paper details how, in a PC Local Area Network (LAN) environment, using SAS version 6.03 and BASIC, we addressed the issues of record and table locking and investigated the data integrity issues that arose. The results can be extended to other operating environments where shared access is desirable, but SAS/SHARE software is not available. f'., t l ', f;.. )i t f H f: g f k f!,. I, J j. oj; ; : INTRODUCTION SPS are a consultancy of around 25 employees, with offices in Woking, England and a sister company, ESPS, in Antwerp, Belgium. We specialise in consultancy and training in SAS and other 4GLs, and in the area of database systems. Our in-house marketing database is written in SAS using SAS/FSP andsas/af. The database holds details of around 1800 contacts and their companies. Historically, this database was held as a stand alone system with access restricted to one user at a time. As the company grew, and more people needed access to the data, each user was allocated their own subset of the data, to permit simultaneous 'access. This meant that data had to be later recombined for reporting :purposes. With the. introduction ofa Locai. Area Network to' our computing envitonment, we, wex:e able to consolidate our system:s, allowing centralised support andshare'd access to data. In doing this we had to introduce some sort of control of concurrent access to SAS datasets at the dataset and observation level. This was implemented by table (dataset) and record (observation) locking techniques. Reporting access to the data is controlled by copy management procedures - a full copy of the data is taken periodically, ensuring the data remains sorted and unchanged while reporting takes place. ENVIRONMENT The techniques. described here could in theory be transferred to any other operating environment supporting SAS 6.03 or later, and allowing shared access todata. 1 The system described uses PC SAS version 6.03 running under DOS version 3.3 and a Local Area Network using Novell Netware version The.networking software permits shared access to,dosfilesheldon the LAN.. Control of shared access to files is '. the responsibility of the software package or system developer. To enable' shared access to network files, the Netware FLAG command' is used to flag datasets as SHAREABLE READ WRITE, and FSEDIT screens and AF catalogs as SHAREABLE READ-ONLY. The SHAREABLE flags mustbe reset by Netware commands if a dataset is : i.. \.,. 139

2 replaced (eg by a DATA step or SORT procedure). Users of the system are given the appropriate Trustee Rights (Read / Write / Open etc) to the directory containing datasets and / or catalogs. This is controlled by the system SUPERVISOR using the Netware GRANT and REVOKE commands. The system also uses BASIC to assist with TABLE and RECORD LOCKING as described below. TABLE (DATASET) LOCKTNG Some. activities will require exclusive access to a dataset. This is achieved by a technique known as table locking, or in SAS terms dataset locking. Logic flow for dataset locking T-: LOCK DATASET lnr: I IS DATASET ---> YES IS DATASET'------>YES RUN PROGRAM ACCESS DENIED ACCESS DENIED UNb <:----'1 DATASET I EXIT <: ' Dataset locking restricts access to a dataset to one user, allowing that user to perform data management facilities such as sorting or performing global updates. Any request to access the data must check to see if the dataset is already locked. A request to lock the dataset must also ensure that no one is currently accessing the dataset. There are therefore three cases: 1. The dataset is locked by another user. 2. The dataset is in use by another user. 3. The dataset is not locked or in use. Implementing dataset locking A dataset can be marked as locked by the existence (or otherwise) of a DOS file. If the file already exists, the dataset is locked by another user and cannot be accessed. By using an external file, we have the flexibility to control dataset locking from within or outside the SAS environment. If the dataset is not already locked, the system must check to see if there are any other users already accessing the dataset. The easiest, and surest way of doing this is to. check if the dataset is already open. This can be done by attempting to open the dataset with LOCK-READ access (only one user at a time). This facility is not available using the SCL of version 6.03, so we used a BASIC program. The code for this program is shown below. 100 REM DBLOCK.BAS DAB, SPS, March REM Checks for LOCKED access to the marketing database 120 REM this involves two datasets PERSUK and COMPUK 130 REM The program generates a simple SAS program INUSE.SAS 140 REM This has one line, %LET INUSE=. ; 150 REM INUSE is 1 (one) if either dataset is OPEN, 0 (zero) otherwise 160 REM 200 INUSE=O 210 ON ERROR GOTO OPEN "F:\APPLIC\MARKDB\PERSUK.SSD" LOCK READ AS OPEN "F:\APPLIC\MARKDB\COMPUK.SSD" LOCK READ AS OPEN ". \DBLOCK. SAS" FOR OUTPUT AS PRINT -113, "'LET INUSE="; INUSE; ";" 250 CLOSE 260 SYSTEM 500 INUSE=l 510 RESUME NEXT Figure 1. BASIC program DBLOCK This INUSE.SAS program generated. can be brought into the SAS session by using %INCLUDE. The. setting of the INUSE macro variable informs the application of whether the datasets are. locked. Note that in this case from our own system, two datasets are being locked as our application program requires access to both datasets Checking dataset for normal access Before any access to the data is attempted, the dataset lock file must be checked to see if it is set. This can be done in SAS or within a DOS BATCH (.BAT) program. If the file exists, access is denied. If not the user is permitted access to the dataset. 140

3 Logic flow for nonnal access :IS DATASET ----> YES T RUN PROGRAM ACCESS DEN:IED Ei:IT <: ----,I RECORD (OBSERV ATIONl LOCKING When 'a dataset is being edited, it is possible (and often likely) that -two users wiiltry,to access the same observation at the same time.,ifthishappeils, it is necessary to ensure_that here is no conflict caused by the two users making different modifications to the observation. The technique to control this is known as record locking, or in SAS terms, observation locking. SAS/ A vs SAS/FSJ> Both SAS/AF and SAS/FSP software now support the, Screen Control Language (SCL) which we considered necessary to control observation locking. The SCL ailow8very powerful control of on screen data, and enables automatic changes to the data}vithout user intervention. We considered the feasibility of writing the system using a SAS/ AF PROGRAM screen to edit data in a query based system, but it was decided to use FSEDlT as the basis for the system, as this avoided reproducing the functionality of PROC FSEDlTwithiIl SAS/AF; and so made the system much less complex. As the existing system already used PROC 'FSEDlT, this also greatly, simplified development. Implementing observation locking Observation locking may be implemented on any dataset by the additioil of an INUSE variable to flag 'when 'the observation is in use. The dataset must be edited in an FSEDlT environment with an associated screen holding the SCL code. When an observation is accessed, the SCL is used to detect if,the INUSE flag is already set. If the flag is set, the user must be denied access to that observation. If the flag is not set, the SCL sets the INUSE flag, and allows the USer to edit the observation. When the user leaves that observation, the flag is once again reset to blank. Access to an observation may be denied to a user by issuing' a FORWARD or BACKWARD command using the CALL EXECCMDO function. This will pass the user on to the next, or previous observation, and' the observation locking checks'must be run again. The direction bftheforw ARD or BACKWARD command can be made dependant on the users previous action. The WORDO function allows you to capture,commands issued by' the user (including commands issued by pressing function keys). If the, user issues a.. FORWARD command, and the next observation is locked, the SCL will also issue a FORW ARD command. Similarly if the user issues a BACKWARD command, the SCL will also issue a BACKWARD command. Example: After editing observation 6, the user enters BACKWARD. Observation 5 is in use, so the SCL issues another BACKWARD command and the user is left editing observation 4. We found it impossible within FSEDlT to detect whether the observation being edited is therrrst (or last) in the dataset, as some observations may have been deleted. This illformation may be needed when the locked record is at the start or end of the data.. Instead, we used' the CUROBSO function to detect a failed,page request, and the direction of the page request is reversed. This method allows several users to access 'different observations of a SAS, dataset,without conflict. ' The saine FSEDlT creen with,its SCL may be used by all users of the system by making the FSEDIT screen SHAREABLE as mentioned above. Note" that, access MUST be controlled by an' FSEDlT screen, and so simultaneous editing with (eg) PROC FSPRlNT can not be controlled. 141

4 Further enhancements In our system, we used two flags to indicate that the observation was in use: USRNAME name of user USRDATE date of edit This enables two extra facilities. Firstly, if an observation is locked, the user trying to access the observation can be told who has locked it. Secondly, should the system fail (eg from a power failure) and the observation is left locked, the system can automatically correct for errors. If an observation is flagged with the users own user name, or with a different date, the flag is assumed to be in error, and can be ignored. We use the Netware WHOAMI command to generate a Macro variable USRNAME set to the LAN user name, which is assumed to be unique for each user of the system at anyone time. This macro variable is generated by running the BASIC program below, and using %INCLUDE to run the program generated. 10 REM WHOAMI.BAS AJP, SPS, March REM This program uses the LAN WHOAMI command 30 REM to generate a simple SAS program WHOlU\I SAS 40 REM This bas one line, 'LET usrname=... ; 50 REM This is used to define a macro variable USRNAME as the LAN user ID 60 REM 100 SHELL "WHOAMI>whoami.dat" 110 OPEN "whoami.dat" FOR INPUT AS OPEN "whoami.aaa" FOR OUTPUT AS DUM$ s INPUT$(13,#1) 140 TEMP$ =INPUT$(20,#1) 150 N = INSTR(l,TEMP$," ") 160 USER$ = LEFT$(TEMP$,N-l) 170 PRINT,2,"%LET USRNAME=";USER$;";" 180 CLOSE 190 SYSTEM Figure 2. BASIC program WHOAMI The next two pages list an SCL program that can be used to implement observation locking oh any SAS dataset Program name: RLOCK SCL program Author: Tony Payne, SPS, March 90 Description: Allows record locking in a multiple user FSEDIT environment. Each record is flagged with the user-id as the record is edited. If a record is already flagged, issue a PAGE command in the same direction chosen by the user. If beginning or end of file, reverse direction (this is detected by a failed page request). Requirements: Dataset must have a Character variable USRNAME length 8, and a numeric variable USRDATE. These MUST be included on the FSEDIT screen, and should be marked PROTECT/NON-DISPLAY. Macro var USRNAME must be set to user-id before running Program WHOAMI TODAY DIRECTN MYMSG LASTOBS variables: Re.tains value of macro variable USRNAME Retains today's date Indicates 'direction' of last PAGE UP/DOWN request Retains a message until it is ready to be displayed Tracks the observation no of a PAGE UP/DOWN request Program notes: The DUMMY command is supported by FSEDIT but does nothing. This does however allow us to check on the consequence of the commands that the SCL issues. This was found necessary to distinguish between user-issued commands and SCL-issued commands. As the program uses CALL EXECCMD, messages passed via MSG may not be seen by the user, Using the DUMMY command and the MYMSG variable, the SCL only displays the message when the user will see it ; LENGTH mymsg $60 directn whoami $8 lastobs 3; 142

5 FSEINIT: CONTROL ALWAYS TERM; 1 SCL runs after each ENTER, EXECCMD and when 1 1 the user exits the observation. 1 lastobs = 0; who ami - SYMGETC( 'usrname' ); today TODAY(); INIT: / check flags when user first enters the observation 1 IF usrname = _BLANK_ / record is not flagged as in use allow editing 1 OR usrname = whoami / record flagged as in use by this user flag in error so allow editing 1 OR usrdate NE today 1 record flagged as in use on another day / 1 - flag in error so allow editing 1 THEN DO; usrname = whoami; usrdate = today; CALL EXECCMD( 'SAVE; DUMMY 1;' ); ELSE DO; mymsg =, User; I I usrname II ' is editing Obs ' II LEFT ( PUT ( CUROBS ( ), 8. ) ) II ' - try later'; IF UPCASE(WORD( 1 ) ) =: 'BACK' OR UPCASE( WORD( 1 ) ) = 'UP' THEN directn = 'BACKWARD'; ELSE directn = 'FORWARD'; CALL EXECCMD.( directn I I '; DUMMY 2;' ); MAIN:. / Capture page requests and display messages (if any) / IF WORD( 1 ) =: 'FORWARD' OR WORD ( 1 ) = 'BACKWARD' THEN lastobs = CUROBS( ); ELSE IF WORD( 1 ) = 'DUMMY' THEN DO; IF WORD( 2 ) = '1' THEN DO; MSG - mymsg; IF MSG NE BLANK THEN ALARM; mymsg --BLANK; ELSE IF lastobs = CUROBS( ) THEN DO; IF dij;ectn ='FORWAlU)' THEN CALL EXECCMD( 'BACKWARD;' ); ELSE CALL EXECCMD( 'FORWARD;' ); TERM: / Reset flags when user exits observation IF UPCASE( WORD( 1 ) ) - 'SAVE' THEN IF usrname =whoami THEN DO; usrname = BLANK; u.srdate :BLANK:i 1 CONCLUSION In allowing shared access to SAS datasets, we achieved several objectives. All Marketing data is now accessed via a central system. All four of ourinarketing versonnel can now access and update data siinultaneously (Figure 3). '. Data available for browsing and reporting is more up to date. We now have only one system to support instead of three as before (Figure 4). \ \ 143

6 o -.1l1li9 1IIB8 Figure 3. Figure o Many thanks to the staff of SAS UK at Marlow for their invaluable assistance and technical support. SAS, SAS/AF, SAS/FSP and SAS/SHARE are registered trademarks of SAS Institute Inc., Cary, NC, USA. Copies of this paper or further information can be obtained from: Tony Payne SPS Ltd, Regent House The Broadway Woking Surrey GU2l 5AP United Kingdom Telephone UK: (0483) International: l - FOOTNOTE 1. After discussion on this paper at SEUGI 90, with the SAS system developers, the following should be pointed out. It is a peculiarity of the Novel Network that permits this system to work. The methods used may work in other environments, but extensive testing should be carried out to ensure data integrity. In most operating environments, SAS protects against simultaneous access to datasets and so the methods proposed wiunot work. The SAS system does not in itself support shared access to data. Because of this it is possible for data to be corrupted unless great care is taken to prevent potential errors. The system proposed here is not 100 percent perfect. Known problems include the possibility of two users accessing the sam observation at the same time (ie within 1/10 seconds of each other) and two users ADDING observations in FSEDIT. It would be possible to tie up these loopholes by using an AF based system. Having said this, in use the system has proved reliable enpughforour needs; and in four months of use, no problems have occurred. 144

FSEDIT Procedure Windows

25 CHAPTER 4 FSEDIT Procedure Windows Overview 26 Viewing and Editing Observations 26 How the Control Level Affects Editing 27 Scrolling 28 Adding Observations 28 Entering and Editing Variable Values 28