SASIAF Software Information Systems on Multiple Platforms: Welcome to the Real World Burtt Blodgett, Quantum Consulting Inc. John Powers, Quantum Consulting Inc. LDAW Will use the remote submission features of SASICONNECT Abstract to support other platforms. The LDAW project is still under active development, and LOAW 3.0 is scheduled for release later this The Load Data AnalysiS Workstation (LDAW) is a SAS/AF® year. LDAW 3.0 will run under Windows and SunOS, and wilt use app6cation developed by Quantum Consulting Inc. for the Electric SAS/CONNECT to provide support for remo_te processing and Power Research Institute (EPRI). LDAW is designed to accass. Integrated networked environments. analyze, and present data collected from electric utility load research programs. LOAW serves as an intuitive front-end to Rgura 1 more than 100 SAS® programs. Atthough originally designed to operate within a PC environment, SAS transport facilities and LDAW Release History SAS Multi·Engine Architecture® have allowed the LDAW to be successfully ported to UNIX and MVS with only a modest amount Date Version MS-DOS Windows UNIX MVS of effort. However, managing multi-platform development and (SAS 6.04)(SAS 6.08) (SAS 6.07) (SAS 6_07) _ support is a difficult and at times overwhelming task. This paper addre~s many issues involved in multi~platfonn development, June 89 O.4RG x and w,lIreveal SASICONNECT® as a solution for many multi· June 90 O.SRG x platform development and network. connectivity issues. June 91 1.0 x June 92 1.2 x x x Dec 92 2.0 x x Introduction May 93 2.1 x remote remote Sept 93 2.2 x remote remote Dec 93 3.0 The LDAW was developed in response to a need for a flexible. x x remote PC·based tool for the analysis of load data. The users of this tool are utility load research and demand·side management (DSM) analysts. These analysts typically have worked with SAS on a LDAW System Design mainframe bafore, but now work with many other PC·based tools. The goal of the LDAW has been to provide a cost-effective data The LOAW is a means of unifying commonly used load research analysis tool which complements these other sottware tools while SAS programs into a coherent system that allows non~ taking advantage of the SAS expertise of utility analysts. This programmers to perform SAS analysis. The LDAW consists of goal was established through initial LDAW Use~s Group meetings over 100 SAS programs that perform various an_alysis tasks. and. conferences that stee~ the project towards an open system These programs, or .S files"are modularized so that variable desgn ba~ on SAS within a PC environment. For this reason, parameters are referenced as SAS macro variables. A SAS/AF early versions of the LDAW were designed and written in SAS front-end provides a common interface to the .S files, and allows 6.04 for MS·DOS®. The LDAW release histol'( is summarized in parameters to be set from within a user-friendly system. For each Figure 1. The LDAW project went through a lengthy initial design .S file there is an SCL programentl'( within a SAS/AF catalog. phese in which two EPRI research-grade versions. LDAW 0.4 and Input parameters on each SCL program screen correspond to the LDAW 0.5, were developed and released for testing. commental'(, SAS macro variables tha,t are referenced in each . S file. The and reaction. These early research grade releases and the first pmenu facility is used to provide a menu system that accesses EPRI production-grade release, LDAW 1.0, were available for the SCL program screens. The menu system organizes progranlS execution within a PC environment only. under pull..oown menu head'ngs,that correspond to categories of analysts tasks, such as data input, data validation, data analysis, Although the MS·DOS versions of LDAW are widely used, some and graphing. After selecting a program from the menu, the user LDAW users find this to ba restrictive. In perticular, the 640K can_enter input parameters, aided by SCL selection lists. A series memory barrier, slow processing speed, and poor data of SCL routines provides error trapping in order to validate user management capabUities in the PC environment are cited as big input When all input parameters are set, an eXElCution mode is problems. Even though the new Windows release of SAS solves selected to run the program. The input parameters are then some of these prob.lems, many potential users do not want to give passed into SAS macro variables in an SCL SUBMIT block. and up the company-Wide data access capabilities available through the relevant .S file is called using a %include statement flelr m8lnfiame system. These users voice concern that moving data from a central server will ultimately result in data integrity The user can choose between three different execution modes. problems that will cause analysis studies to be incomparable. Immediate mode causes the program to ba submitted to SAS for Many users also want to have the LDAW take advantage of more immediate e~ecution. Batch mode saves the program in a file for ; powerful platforms that are available to them. These are later execution. Programs can be added on to a batCh file to , legitimate concerns, ant.! subsequent versions of the LOAW have create more complex analysis routines. In the newest version of been ported to run on other plaNorms. Beta versions of LDAW LDAW, a remote mode submits the program or batch file to a 1.2 have been ported to run under SAS 6.07 for SunOS®. SAS remote host for execution. 6.07 for MVS, and SAS 6.08 for Windows. However, the PC is still the main plaNorm for LDAW. Since the Multiple Platform Development majority of LOAW users still use the PC environment new versions of the LDAW are developed for the PC first T~ most A platfonn is a combination of an operating system with a recent release of the LDAW, LDAW 2.0. is currently available for hardware configuration. Development of the LOAW under MS·DOS and Windows only. Current and planned LDAW multiple platforms has created special problems and solutions. development is being performed exclusively in Windows. The biggest problem is version control. This issue involves the Because porting and maintaining several versions of the LDAW process of creating software that worlts the same way on every on different platforms is resource intenSive, future releases of platform. It also involves managing bug fixes and software 601 updates. Version control is effected by differences across SAS consists of computing summary statistics, duty cycle distributions, releases, and by differences between operating systems on and load control impacts from the same input dataset. This job is different platforms. The following sections will explore multi­ more heavily weighted toward CPU processing. Finally, the platform software development, and will emphasize the' role of 'Graph' job consists of computing and displaying monthly and 3-0 SAs/CONNECT as a solution for many current version control load profiles for each of the 20 sites in the input dataset This job issues. is heavily weighted toward graphics display speed. The three jobs were run on 10 different platforms. Six different Why Support Multiple Platforms? personal computers running DOS 5.0 were tested, ranging from a 12-MHz 80286 machine to a 66-MHz 80486 machine. The 486 There are many reasons to support multiple platforms. The most was eight to twelve times faster than the 286. These DOS tests important reason is that evelY user is different. Every user has were performed using PC/SAS 6.04. More impreSsive, however, different needs, pralerances, and favorite softwara packages that is the ,speed improvement available with a 486 machine running they absolutely must have. Organizations have different Windows 3.0 or 3.1. The Windows tests were performed using requirements that will fit within their corporate culture. Some the Develope(s Release of SAS 6.08 for Windows. The same users may only be familiar with a mainframe, while others 486 ran from 2 to 4 times faster under 6.08 for Windows than wouldn' recognize a line of JCL if it jumpad at them. In order to under 6.04 for DOS. The commercial release of SAS Version satisfy all users, a softwara system needs to be able to support a 6.08 for Windows has recently become available, but does not variety of platfonns. The bottom line is that users want data appear in this test processing to take place on the platform in which they feel most comfortable. Users are unwilling to move all of their data and Four different Sun SPARCstations running SunOS 4.1 and analysis tools off of a familiar system and onto a new and OpenWindows® 3 were tested. These include a SPARCstation unfamiliar system that mayor may not be better. A platfonn is not IPX, a SPARCstabon 2, a SPARCstation 10, and a SPARCserver chosen besed on the availability of one softwara package. 630 MP. The four machines all have the same internal CPU, ' although the SPARCserver 630 has four of these CPUs. All four A modem computing environment often contains many different machines ran each benchmark much more quickly than the analysis platfonns. The computing facilities available within a fastest times for PCs. For example, the IPX ran the Loadstone large corporation typically combine mainframes, mini computers, job in less than one-tenth the time of the 486 running DOS. The UNIX workstations, IBM personal computers, and Macintoshes. new SPARCstation LX and SPARCciassic will probably give To be successful, modem softwara systems must be available to perfonnance similar to a SPARCstation 2.