Using SAS/SHARE More Efficiently

Transcription

1 Using More Efficiently by Philip R Holland, Holland Numerics Ltd, UK Abstract is a very powerful product which allow concurrent access to SAS Datasets for reading and updating. However, if not used with care, it can also be the cause of significant system-wide performance problems. Although the product is widely used, its impact is not widely understood. This paper describes some of the potential pitfalls when using, and suggests techniques to gain the maximum benefit from the product. 1. Introduction The MVS operating system has 3 modes of file access. SHR permits read-only access, and OLD and MOD permit exclusive read/write access. Libraries under MVS are single files containing one or more members, e.g. DATA, VIEW, CATALOG, ACCESS, etc. User User Shared Local (read-only) Figure 1. Sharing Libraries without. If a user wants to read and write to sets and Catalogs in a, then the must be allocated to a Reference (libref) as OLD or MOD, which will prevent any other user from allocating it. If a user only wants to read from a, then allocating it as SHR will only permit other users to allocate it as SHR as well for read-only access at the same time.

2 User User Server REMOTE Server SAS REMOTE Server Shared Local (read-only) Figure 2. Sharing Libraries with. A Server can allocate Libraries as OLD, which will prevent any other user from allocating those Libraries directly. However, by using the REMOTE, which is part of, other users can allocate those Libraries as SHR or OLD through the Server. The MVS operating system will see only one allocation, that of the Server, for each so no conflicts will exist between the user accesses. will read and write on behalf of the individual users. As a result, concurrent access can be controlled at a lower level than the default level of, e.g. library member, member record, etc. 2. Performance measurement The following observations were made using the SAS System for MVS release 6.08 running on an IBM mainframe. The client SAS user was a batch job running SAS and the server was another batch job running PROC SERVER under SAS, which were run concurrently. Time comparisons were calculated from information in the SAS Logs from each batch job.

3 Client Resource Consumption Server Client start Read data from Read data from Generate Formats in Generate Formats in Process local data Time Line Process and write data in Process and write data in Client close Figure 3. Relative CPU Resources for Local and Libraries. 2.1 Sequential read of set using a DATA step Local set Client session = 10 CPU seconds, Server session = 0 CPU seconds set in Client session = 11 CPU seconds, Server session = 12 CPU seconds 2.2 Copying a set to WORK using PROC COPY Local set Client session = 10 CPU seconds, Server session = 0 CPU seconds

4 2.2.2 set in Client session = 11 CPU seconds, Server session = 12 CPU seconds 2.3 Generate a SAS Format into a permanent using PROC FORMAT Local Client session = 10 CPU seconds, Server session = 0 CPU seconds in Client session = 11 CPU seconds, Server session = 110 CPU seconds 3. Coding examples 3.1 Coding without considering overheads The following code will use about the same CPU time in the Client session and in the Server session, and the Client session will consume about 10% more CPU time than the equivalent code running with a local : libname sharelib 'PROJECT.GROUP.SASDB' disp=old server=sharesrv; data sharelib.ds01; set sharelib.ds00; * start of processing *; * end of processing.. *; output; run; 3.2 Coding with reduced overheads The following code will use a little more CPU time in the Client session, due to the additional PROC COPY steps, but will use much less CPU time in the Server session, as the only processing performed there will be the initial PROC COPY read and the final PROC COPY write of the Dataset: libname sharelib 'PROJECT.GROUP.SASDB' disp=old server=sharesrv; proc copy in=sharelib out=work; select ds00; run; data work.ds01; set work.ds00; * start of processing *; * end of processing.. *; output; run; proc copy in=work out=sharelib; select ds01;

5 run; 4. Further observations Servers are not limited to MVS platforms, and are supported under most of the other platforms supporting the SAS System, including CMS, OpenVMS, OS/2, Unix, Windows NT, Windows 95, VSE and AOS/VS. The following observations were made while working under OS/2 and Netware, although they will all apply to the platforms listed earlier. It is possible to store SAS/AF and SAS/FSP application Catalogs on a Server, but beware of compiling code directly into the -controlled Catalog. As compiling involves a certain amount of random access to the SAS Catalog containing the code, storing that SAS Catalog on a Server will make the overhead on that Server during compilation extremely expensive. It would be cheaper and quicker to compile local copies of the code and then copy the compiled code back to the Server. It is not recommended to put code compiled with the Debug option set on into a SAS Catalog in a SAS Data controlled by, as multiple access to that code module will severely impact the performance of the Server, and may even crash the Server. 5. Recommendations If a set or Catalog must be updated while other users are reading/updating data in the same, then only put those SAS objects into a controlled by. Put SAS data which is only read during the day in a shared and update when no other users are accessing the data (e.g. overnight). Only access sets controlled by in read and update steps, not for processing, as processing time will be mirrored unnecessarily on the Server. If the data on the Server has to be updated, copy the data to a local set, update the data in the local set, then copy the data back into the set controlled by remembering to check that it does not overwrite any data that has been updated by another user since the copy was taken. Avoid random access processing of sets controlled by as the Server will use significantly more resources than the Client task (e.g. PROC FORMAT). Compile local copies of SAS/AF and SAS/FSP code and then copy the compiled code back into the SAS Catalog on the Server. Do not put code compiled with the Debug option set into a SAS Catalog in a controlled by, as multiple access to that code module will severely impact the performance of the Server, and may even crash the Server. 6. References and further reading - Usage and Reference, Version 6, First Edition. The author is a consultant for Holland Numerics Ltd and can be contacted at the following address: Philip R Holland Holland Numerics Ltd

6 94 Green Drift Royston Herts. SG8 5BT UK tel. (mobile): +44-(0) SAS,, SAS/AF and SAS/FSP are a registered trademarks of SAS Institute Inc., Cary, NC, USA.