OS/2® SAS Server Using SAS® Software in a Networked Client-Server System
Total Page:16
File Type:pdf, Size:1020Kb
OS/2® SAS Server Using SAS® Software in a Networked Client-Server System Allan E. Williams David West Fred Hutchinson Cancer Research Center, Seattle, WA. ABSTRACT would also free up their computer for other tasks while large jobs were running on the remote SAS server. For users of the SAS System 6.04 on PC networks, the release of the SAS System 6.06 for the IBM OS/2 operating system brought both exciting opportunities and Requirements: accompanying problems. The SAS System 6.08 for OS/2 is much faster, as well as allowing larger jobs and new To be effective, a SAS Server needed to satisfy the capabilities. However, upgrading all SAS users to OS/2 is foll9wing objectives. First, The server should use the impractical for many environments. same network SAS system files as the SAS System 6.04, without conversion or transportation to a different This paper discusses one solution that enables all SAS location. This is not possible ~ the files are to be users on a PC network to take advantages of the new process~d on a UNIX computer on the network. Sharing features and throughput of the SAS System 6.08 for OS/2 files between the PC SASSystem 6.04 and the UNIX without having to convert operating systems. SAS system require conversion to intermediate transport files via PROC CPORT and PROC CIMPORT. Files A simple approach to implementing an OS/2 SAS server would then have to be copied between UNIX network disk on a network is described. Examples of the use of the partitions and DOS network disk partitions and then SAS server are described and future enhancements and converted by a DOS to UNIX utility. In contrast, the SAS possibilities are discussed. Extensions from a single System 6.06 on OS/2 can read and write PC SAS System OS/2 SAS server to multiple servers on the network are 6.04 system files directly. straight forward. Multiple batch servers create a 'cluster' of processors that appear to the user like one large A second requirement was that use of the SAS Server server. requires minimal conversion, ~ any, of SAS jobs. In additiOn, it was important to allow a user to decide where to run a particular job, since the SAS Server may have a INTRODUCTION: long queue at times. The environment that provided the impetus for Third, the user should be able to use the same habits consideration of a SAS server was a large PC Novell® when using the SAS server or the PC SAS System 6.04. network serving a group of social scientists, Thus ~ the job is run in batch mode, the SAS '.lOG' and epidemiologists, and biostatisticians involved in cancer '.lST' files should be left in the same location, regardless prevention research. The investigators, programmers, of where the job is run. and analysts use the PC SAS System 6.04 for all analyses. Many survey data sets have over 500 A final but very important design element was to use a variables and SAS jobs tend to run out of computer simple and modular approach to develop the SAS Server memory. In addition, some new features of the SAS system. System 6.06/6.08, particularly PROC SQl, were very important to several projects. Solution: It was not practical to convert all SAS users to OS/2 so Consideration was given to implementing the SAS Server that they could use the SAS System 6.06, since many of in SAS MACRO or in a batch programming language the other important computer tools were not available on such as OS/2 REXX. The latter was chosen, because OS/2. Converting a few machines to OS/2 was the approach would then work on any batch job that could problematic because each person worked cooperatively be run under OS/2, not just SAS. (REXX is part of OS/2.) on multiple projects, and all people on a project had to Further, developing the pilot program in an interpreted access the same SAS system files. batch programming language allowed for the most flexibility and simplicity. Most PC SAS users in our environment tend to run SAS in batch mode, since it reduced the out-of-memory Network communication between all users was a major problems and because most preferred using their own concern, since not all users have read or write permission editor. We reasoned that ~ it were possible to submit a on all parts of the network. A common communications batch SAS job to a remote PC running SAS on OS/2 then directory was used that all users had access to for the we could provide them access to the SAS System 6.06 SAS Server queue and log files. features without a change of operating system. This 474 The main function of the OS/2 Server (DOSAS.CMD) is The Users View on MS-DOS: to read from a queue file the name of a SAS job to be run, the directory in which the job resides, and to wr~e the In order to submit a job (for example, test1.sas) to the time spent to a log file after the job is finished. OS/2 SAS Server the user types: Two Pascal programs were written for the MS-DOS side. OS2SAS TEST1.SAS The first program, OS2SAS, subm~s a SAS job to the queue and/or shows the list of jobs in the queue. Another This starts the OS2SAS program, and passes the name similar program, DELSAS, deletes a job from the queue. of the SAS job to the queue. The OS2SAS program wr~es the name of the SAS job (TEST' .SAS) and the full One implication of requiring the SAS Server to read SAS directory name to the queue file in the shared jobs submitted from any directory is the SAS Server 'user' communications area. must have very broad permissions on the network. A special Novell user, named 'SASSERV' was created to The. results of submitting this job is shown below. Note run the SAS Server. Because of the broad permissions that there are several jobs already in the queue, and that required, the SAS Server computer has limited access, the job TEST' .SAS shows up as the last line, but w~h and limited key personnel can bring up the SAS Server '.TMP' as the extension. This is because a copy of the and log into the network. SAS job is made before submission. A 25 Mhz 486 level PC (IBM PS/2) was chosen as the M:\SASEX> os2sas test1.sas in~ial SAS Server computer. OS/2, version '.3 was installed with Novell network access. The computer has 1 file(s) copied 8 MB of memory, which was adequate for most SAS jobs Submitted M:\SASEX\TEST1.SAS but proved to be too limited for some large SAS/IML® for SAs/OS2 processing jobs or to run simu~aneous SAS jobs. A larger server (50 Mhz 486 PC clone w~h 24 Mb memory, OS/2 2.0) was CONTENTS OF QUEUE FILE: then installed and no limitations were observed. Many of M: \BER\CODE MAKEBASE.TMP our large jobs are I/O limited and the access speed to the M: \BER\CODE MAKEIBAS.TMP network is critical. Our network is a '6MB/Sec IBM M: \BER\CODE FIXIBASE.TMP Token Ring, and the file server uses striped disk arrays M: \BER\CODE FIXBASE.TMP for high speed file access. Since all data is shared M: \TEST\CODE CONTENT.TMP between users the data is always stored on the network. M: \sASEX TEST1.TMP Software is also obtained from the network server for s~e licensing control. If the user leaves off the name of the SAS file, the program displays the contents of queue. This is shown below. Starting the OSI2 SAS Server: M:\SASEX> os2sas The following steps are followed to bring up the SAS Server: CONTENTS OF QUEUE FILE: M: \BER\CODE MAKEBASE.TMP • Start OS/2 SAS Server M: \BER\CODE MAKEIBAS.TMP • Log into Novell as SASSERV M: \BER\CODE FIXIBASE.TMP • Bring up an OS/2 batch window M: \BER\CODE FIXBASE.TMP • Start the DOSAS REXX program. M: \TEST\CODE CONTENT.TMP M: \SASEX TEST1.TMp· What happens on the OS/2 SAS Server? The user can check the .LOG and .LST files to see d the job is finished, just as would be the case submitting the The DOSAS program reads the queue file for jobs job as a batch PC SAS System 6.04 job. Our convention submitted by users. A 'job' consists of the name of the is to issue a Novell 'SEND' command using the SAS SAS program to be run, and the full name of the network 'CALL SYSTEM' function in conjunction with the directory that submitted the job. When a 'job' is found, NOXWAIT option to alert the user that the job is finished. the DOSAS program changes to the directory indicated NOTE: This does not work effectively if the user is in and starts the indicated SAS job. Windows. When the job finishes, control returns to the DOSAS If the user wishes to delete his/her job from the queue, REXX program. The DOSAS program wr~es the date, there is a second program, DELSAS. To delete the job job execution time in seconds, and the directory and SAS TEST' .SAS from the queue, the user types: file name to the log file. The program then returns to the communications area and continues looking for more jobs DELSAS TEST1.SAS to run.