Welcome to the Real World SASIAF Software Information Systems on Multiple Platforms: Burtt Blodgett, Quantum Consulting Inc. John Powers, Quantum Consulting Inc.
LDAW Will use the remote submission features of SASICONNECT to support other platforms. The LDAW project is still under active Abstract development, and LOAW 3.0 is scheduled for release later this year. LDAW 3.0 will run under Windows and SunOS, and wilt use (LDAW) is a SAS/AF® The Load Data AnalysiS Workstation to provide support for remo_te processing and Inc. for the Electric SAS/CONNECT app6cation developed by Quantum Consulting Integrated networked environments. Power Research Institute (EPRI). LDAW is designed to accass. utility load analyze, and present data collected from electric Rgura 1 research programs. LOAW serves as an intuitive front-end to designed to more than 100 SAS® programs. Atthough originally LDAW Release History operate within a PC environment, SAS transport facilities and have allowed the LDAW to be SAS Multi·Engine Architecture® Date Version MS-DOS Windows UNIX MVS only a modest amount successfully ported to UNIX and MVS with (SAS 6.04)(SAS 6.08) (SAS 6.07) (SAS 6_07) _ of effort. However, managing multi-platform development and task. This paper support is a difficult and at times overwhelming 89 O.4RG x development, June addre~s many issues involved in multi~platfonn June 90 O.SRG x for many multi· and w,lIreveal SASICONNECT® as a solution 91 1.0 x issues. June platform development and network. connectivity June 92 1.2 x x x Dec 92 2.0 x x May 93 2.1 x remote remote Introduction Sept 93 2.2 x remote remote Dec 93 3.0 x x remote The LDAW was developed in response to a need for a flexible. PC·based tool for the analysis of load data. The users of this tool are utility load research and demand·side management (DSM) a LDAW System Design analysts. These analysts typically have worked with SAS on with many other PC·based tools. mainframe bafore, but now work The LOAW is a means of unifying commonly used load research been to provide a cost-effective data The goal of the LDAW has SAS programs into a coherent system that allows non~ complements these other sottware tools while of analysis tool which programmers to perform SAS analysis. The LDAW consists SAS expertise of utility analysts. This taking advantage of the over 100 SAS programs that perform various an_alysis tasks. through initial LDAW Use~s Group meetings goal was established These programs, or .S files"are modularized so that variable project towards an open system and. conferences that stee~ the parameters are referenced as SAS macro variables. A SAS/AF PC environment. For this reason, desgn ba~ on SAS within a front-end provides a common interface to the .S files, and allows designed and written in SAS early versions of the LDAW were parameters to be set from within a user-friendly system. For each LDAW release histol'( is summarized in 6.04 for MS·DOS®. The .S file there is an SCL programentl'( within a SAS/AF catalog. a lengthy initial design Figure 1. The LDAW project went through Input parameters on each SCL program screen correspond to the research-grade versions. LDAW 0.4 and phese in which two EPRI SAS macro variables tha,t are referenced in each . S file. The released for testing. commental'(, LDAW 0.5, were developed and pmenu facility is used to provide a menu system that accesses research grade releases and the first and reaction. These early the SCL program screens. The menu system organizes progranlS release, LDAW 1.0, were available for of EPRI production-grade under pull..oown menu head'ngs,that correspond to categories PC environment only. execution within a analysts tasks, such as data input, data validation, data analysis, and graphing. After selecting a program from the menu, the user of LDAW are widely used, some Although the MS·DOS versions can_enter input parameters, aided by SCL selection lists. A series ba restrictive. In perticular, the 640K LDAW users find this to of SCL routines provides error trapping in order to validate user processing speed, and poor data is memory barrier, slow input When all input parameters are set, an eXElCution mode in the PC environment are cited as big management capabUities selected to run the program. The input parameters are then the new Windows release of SAS solves problems. Even though passed into SAS macro variables in an SCL SUBMIT block. and many potential users do not want to give some of these prob.lems, the relevant .S file is called using a %include statement up the company-Wide data access capabilities available through These users voice concern that moving flelr m8lnfiame system. The user can choose between three different execution modes. will ultimately result in data integrity for data from a central server Immediate mode causes the program to ba submitted to SAS analysis studies to be incomparable. for problems that will cause immediate e~ecution. Batch mode saves the program in a file the LDAW take advantage of more to Many users also want to have later execution. Programs can be added on to a batCh file are available to them. These are of ; powerful platforms that create more complex analysis routines. In the newest version subsequent versions of the LOAW have a , legitimate concerns, ant.! LDAW, a remote mode submits the program or batch file to Beta versions of LDAW been ported to run on other plaNorms. remote host for execution. 1.2 have been ported to run under SAS 6.07 for SunOS®. SAS 6.07 for MVS, and SAS 6.08 for Windows. the Multiple Platform Development However, the PC is still the main plaNorm for LDAW. Since majority of LOAW users still use the PC environment new platfonn is a combination of an operating system with a of the LDAW are developed for the PC first T~ most A versions configuration. Development of the LOAW under of the LDAW, LDAW 2.0. is currently available for hardware recent release created special problems and solutions. only. Current and planned LDAW multiple platforms has MS·DOS and Windows control. This issue involves the exclusively in Windows. The biggest problem is version development is being performed the same way on every of the LDAW process of creating software that worlts Because porting and maintaining several versions software of platform. It also involves managing bug fixes and on different platforms is resource intenSive, future releases
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. Although these new support an increasingly broad number of users on a wide variety ma:chines are very competitively priced, they only run Solaris® of systems. 2.0, which SAS does not currently support.
Unfortunately, computer users are notoriously snobbish about the ~I of the ~sults in Figure 2 are based on singl$ user processing. ope'rating system they use, and will often subject a weary listener Figure 3 shows how the performance of the Analyze job changes to lengthy diatribes about the merits of their system of choice. when multiple SAS sessions are in use. There are some Even worse, they are often unwilllng to touch or even consk:ler the additional aspects to running the LDAW under UNIX which should use of hardware that uses a different operating system. It has be noted. First, as shown in Figure 3, the performance of UNIX been said half-jokingly that operating systems are Uke religions. workstations depend~ critically on how many jobs are running Anyone who has watched the sparks fly when a UNIX workstation concurrently. For example, the IPX can run five copies of 'the user, a PC user, and a mainframe user are placed in the same Analyze job simultaneously, in less time than it would take to' run room knows that this is an understatement Such debates often them sequentially; This means that the IPX is even faster than have, a felVOr usually reserved for Sunday morning televangelists the single-user benchmarks shown in Figure 2 imply. preaching the gospal. Although every platform has its advantages and disadvantages, the best operating system. like a religion, is a Finally, these benchmarks are for small to medium-sized jobs, so matter of preference. a substantial part of the time shown for the UNIX machines is for overhead associated with starting SAS. With larger jobs, the Platforms can be compared in terms of performance. When the advantages of the UNIX environment would be even more pros and cons of different platforms are discussed, the following pronounced. With its multi-processing capabilities, UNIX permits issues are ineVitably the subject of intense debate. Platform the user to .work. on other programs while jobs execute. This performance issues fall irlto three general categories, processing means that' even- the largest jobs do not hold up the user's speed, operating system data management differences, and p~ress in completing a project. platform support issues. Benchmarking tests of the LDAW under MVS are currently, in progress. Interested readers can contact the authors for more Processing Speed infonnati90 aboufthe MVS benchmarks. results of the benchmarking test reveal that of the machines Obviously, a major differance and selling point between platforms The tested, LDAW runs fastest on Sun UNIX workstations. However, is processing speed. The SAS system runs at different spaeds on differant platfonns. Figures 2 and 3 provide a summary of SAS the results of the test 01 the Developa(s Release of SAS 6.08 for execution times under a variety of hardware/software Windows are moo velY encouraging. Both of these develOpments environments. These..figures Iist'U1e execution times for LDAW will allow the LDAW user to run more jobs interactively, to work SAS jobs on an assortment of platfonns in use by various LDAW with larger da~sets at anyone time, and to be more productive in completing large projects. users, including UNIX wori Three benchmark jobs have been developed for comparison 'of Processing speed is 'important, but it is only half -the story. There the analysis, graphical, and overall performance of the various are a multitude of other features that contribute to a. system hardware/software combinations. The -Loadstone" job consists of preference. Many of these features contrast the centralized smoothing, averaging, and graphing hourty load data from 20 computing environment of a mainframe with the decentralized sites for 30 days. This job contains a good mixture of disk computing environment of workstations and pes. Although a well access, CPU proceSsing, and graphics. The· Analyze" job organized network system can often blur the differences between 602 ,. , Figure 2 LDA W Benchmark Comparison Single-User Processing Platform Loadstone Analyze Graph Personal Computers 486 - 66 Win 3.1 60 120 260 486 - 33 DOS 5.0 200 275 655 386 - 33 250 375 856 386 - 25 450 900 1649 386 - 16 755 1248 3840 286 - 12 750 1100 3795 UNIX Workstations SUN SPARCstation IPX 16 24 152 SUN SPARCstation 2 16 26 101 SUN SPARCstation 10 11 24 35 SUN SPARCserver 630 16 19 66 Note: All times are based on local CPU performance and local disk access. All times are in seconds. 603 Figure 3 LDA W Benchmark Comparison UNIX Multi.Processing Platform SAS Users Analyze Disk SUN SPARCserver 630 1 19 local SUN SPARCserver 630 2 24 local SUN SPARCserver 630 3 31 local SUN SPARCserver 630 4 39 local SUN SPARCserver 630 5 49 local SUN SPARCserver 630 6 60 local SUN SPARCserver 630 7 67 local SUN SPARCserver 630 8 82 local SUN SPARCserver 630 9 88 local SUN SPARCserver 630 1 69 remote SUN SPARCserver 630 2 198 remote SUN SPARCserver 630 3 224 remote SUN SPARCserver 630 4 423 remote Note: The SUN SPARCserver 630MP tested has 4 processors and 64M of memory. SUN SPARCstation 2 1 26 local SUN SPARCstation 2 2 51 local SUN SPARCstation 2 3 62 local SUN SPARCstation 2 4 91 local SUN SPARCstation 2 5 99 local SUN SPARCstation 2 6 112 local SUN SPARCstation 2 7 134 local SUN SPARCstation 2 8 146 local Note: The SUN SPARCstation 2 tested has 32M of memory. SUN SPARCstation IPX 1 24 local SUN SPARCstation IPX 2 50 local SUN SPARCstation IPX 3 63 local SUN SPARCstation IPX 4 85 local SUN SPARCstation IPX 5 97 local SUN SPARCstation IPX 6 125 local SUN SPARCstation IPX 7 146 local SUN SPARCstation IPX 8 174 local Note: The SUN SPARCstation IPX tested has 16M of memory. Note: All times in seconds. 604 centralized and decentralized computing environments. there is contrast, mainframes are often kept in separate facilities with still a big trade off in benafits between platfonns. These include: elaboJate security procedures protecting !hem. • File Management File management capabilities differ from platform to platform. Managing Multiple Platform Development Some operating systems, like UNIX, provide excellent file with SAS management capabilities. These include powerful data management commands that allow the user to rename, move, or On paper, mulli-platfonn development in SAS should be easy. delete files and directories. The UNIX platfonn also includes Theoreticaily, aJl!hat needs \0 be done is to Nn a PROC CPORT support for lots of on-line storage and built..jn data compression. and !he SAS Multi-Engine Architecture lakes care of everything. Other platfonns, such as a mainfram~, constrain the use.r to a In the real wOrld, porting applications is much more difficult. limited amount of on·line disk space, With most storage off.(lne on There are many ways to manage multi·platform development. tapes. This ~n cause leng!hy time delays. Unfortunately, there are no easy solutions. In the following sections we will outline our approach to multi·platform o Backups development A major issue of concem is the availability of automated backups. On mainframe systems, backups 01 data ~lr! performed SAS provides an excellent porting lacility that allows soure<> and automatically at ftaquent intervals. However, thiS IS usually not object code to be directly ported from one operating system to !he case on UNIX workstations and PCs. Some users may only another. This is extremely impressive, and is a feature that is not use systems lhat are automatically backed up by !heir IS group. available with any other data processing language. Although small applications may port wi!hout modification, a large 50,000 • File Consistency line application like the lDAW will definitely need some Many managers are concerned about data consistency across modification. In practice a lot 01 code has to be overhauled to analysis efforts. They will resist efforts to remove data from a resolve differences in SAS versions and platform specific central server and onto a k»caJ system for analysis. changes. Although this may seem disappointing, it is still far better than the porting facilities available with most other • Network Aceess languages. Network access is another area where platforms differ. Many mainframes have company·wide network access that is not SAS/AF catalogs are transferred using PROC CPORT and PROC available on UNIX workstations and PCs. However, UNIX CIMPORT to create transport files. PROC CPORT is used to workstations often come equipped to support fast, modem convert a SAS/AF catalog from the current operating system into networking standards like TCP/IP that provide. superior a transport file that can be moved onto a remote host The PROC connactivity and perfonnance. UNIX systems often provide world CIMPORT procedure then tums tha transport file into a SAS/AF wide access to mail services like INTERNET and UUNET. catalog for the remote operating system. This works very smoo!hly, aI!hough !he NOCOMPRESS option often has to be Ease of Use used. Mainframes are notoriously difficult to use, with 1970's style interfaces that are primitive and confusing. Mainframe SAS data sets can be transferred using the PROC COpy programming often involves the use of dinosaur data procedure. PROC COpy creates a transport file that can be management languages like JCL. However, UNIX workstations copied onto a remote host and 1hen converted into a SAS dataset. and PC's provide modem graphical user interfaces that are more A much better SAS dataset Iransfer lacility is provided through !he intuitive and allow the user to be more productive. PROC UPLOAD and PROC DOWNLOAD procedures available !hrough SASICONNECT. These procedures eliminate !he need for a transport file, saving space on both sides of the transfer. Platform Support Issues SAS programs are easily ported as ASCII files to the remote Platfonn support issUes involve the availability of support and operating system. However, in UNIX a translation must be run to service on different platforms. These issues are often overlooked, convert the file from MS-DOS text to UNIX tex\. In MVS, a but are critical to providing a reliable and effective dala proceSsing character line ~mit must be specified when uploading ASCII files solution. onto the mainframe. Unes that exceed the character line limit are truncated, which will cause a syntax error when the code is run. • Training Another issue of concem is the availability of training services. Our strategy for multi-platfonn development has been to develop Many companies provide training and support services for their production code on the PC platform, and !hen to port !his code to mainframe, but not for UNIX or PCs. remote operating systems. The LDAW consists of two primary parts - the SCL calalog, and !he library of SAS programs, or .S o Support files. The SCl code and the .S files have to be modified to The availability of support services is yet another major issue. resolve platform and SAS version differences. Then the Users like to know who will fix their computer when something application is tested and any platform specific bugs are corrected. goes wrong. On mainframe systems, users never have to worry Unfortunately, the code modification results in versions of the about this issue. code are not exactly the same across platforms, and have Significant differences. This makes it more cumbersome and o Security difficult to test. debug, and maintain code. Many users are increasingly concerned about data security, after many well publicized media reports of viruses, data theft, and Management of multiple platform development is an issue of electronic sabotage. UNIX workstation and mainframe users resolving platform differences. As far as SAS software have logon names and passwords as a first line of defense. UNIX development is concerned, platform differences fall into tv.:o also provideS very good data security, with sepaJate read and groups. There are SAS version differences involving changes an write privileges for individuals and work groups. Although SAS syntax from one release to another. There are also platform probably not an issue to most people, some users'are concerned specific differences that involve changes that are unique to a about the safety of their equipment from theft or vandalism. PC given platfonn. and UNIX workstations are usually kept in low security areas. In 605 SAS Version Differences Platform Specific Differences (SAS 6,04 vs. SAS 6.07, SAS 6.08) There are many dfHerences that are platform specific. These Some major dille",nces between SAS 6.04 for MS-OOS, SAS differences involve changes that are unique to a given platform. 6.07 for MVS, SAS 6.07 for SunOS, and SAS 6.08 for Windows are summarized below. These differences were discovered when Function keys the LOAW code was ported from SAS 6.04 to other plaUonns. Function key definitions do not port with PROC CPORT. In addition, function keys _on the keyboard can differ from system to • Dataset Control level system. This can cause problems with -applications that are set In SAS 6.07 and SAS 6.08, the ctrllev option allows the user to up lor specific func~on key de6nitions. In UNIX, users can define specify member level or group level locking when openifl9 a function keys through their X-defaults, which can also cause dataset A dataset thet is being updated must have a control level appfication problems. specified when it is opened. or an error will occur and execution of the program will be halted. . Concatenation opE!fator In SAS 6.07 for MVS, the concatenation operator ior character Run va Quit strings is a double exclamation point (!!) rather than a double In SAS 6.04, procedu",s can end with a quit statement This pipe (II). causes SAS execution information to, be printed in the log file immediately after the procedure. In SAS 6.07 and SAS 6.08 a run Control ASIS statement must be used or the procedure will not be executed. In ,SAS (t07 for MVS, an 'set control asis statement must be specified in-order for coda that spans more than one line in the Quoting on nUe Statements subm~ block to be correcHy interpreted. A blank tiHe statement in SAS 6.04 can take the fonn of title .. Sort Size In SAS 6.07 and SAS 6.08 this will appear as a quotation mark on On the.-PC platfonn,' ,8_ sortsize option must be specified in a the semen rather than a blank line. PROC SORT for sorting a large dataset. This option will severely degrade perfonnance on UNIX and MVS operating systems if it is PAOC CPORT, Nocompress left at the value used on the PC plaUonn. The nocompress option must be used during PROe CPORT to UNIX and MVS. Note that graphics characters do not transfer 110, Path Structures, and File Referencing across operating systems, which can cause mysterious Path structures are different from operating' system to operating characters to appear on the screen. system. Here are three different path structures ltlat refer to the main LDAW SAS/AF catalog. Any code that references a path • Pmenus structure has to be updated to use the relevant ,structUre. SAS 6.07 and SAS 6.08 can use the pmenu facility as a menuing MS·OOS c:~dawlsctVdaw.sct system within a SASIAF program. The pmenu facility is UNIX lusrAocalJ1daw/sctlldaw.sctOl significantly better than the number choice menus available in MVS LRooot .LDAW.sCT(LDAW) SAS6.04. Graphics " • SCl Label length The appearance of graphics can vary baSe,d on the platform and In SAS 6.07 and SAS 6.08, SCL labels can only be 8 characters device drivers that are used. The same graphics code can long. Any SeL labels longer than 8 characters have to be produce different output ,on different pl~tforms. changed or the program will not compile. • Goptiona Update Management There are many new goptions available in SAS 6.0T and SAS 6.08. SAS 6.04 code has to be changed in order to use these Update management involves upgrading different versions of new goptions. LOAW, ,and managing_ software bugs. Since dev~lopment is perfonned C/n the PC, any software updates are usuany ported Gwindow from the PC to the UNIX and MVS environments . .These updates The gwindow option must be specified in SAS 6.07 and SAS 6.08 are then tested, and any necessary changes are performed. in order to view ,any graphic output. The same procedure is generally followed for managing ~ftware Engines on Ubnames bugs. Some bugs are local, and some bU9s are found .on ,all SAS 6.07 and SAS 6.08 flbname statements can accept enlines plaUonns. When a bug is found, all plaUonns ..are tested, and the that allow access to previous versions of SAS datasets. relevant changes are made. If the bug_ is sufficiently serious, then a notice is placed on EPRINET, tha EPRI user support network. SCl Call Update Users are also supported through EPRI Remote Link software, In SAS 6.04, an SCL call update can use the syntax which allows remote access to EPRI,applications using a modem. rr: = update(dsid,obsnum); However, in SAS 6.07 and SAS 6.08, the following syntax must be used Strategies for Multiple Platform Development rr: = fetchobs(dsid,obsnum); rr: = update(dsid); The Bed Old Days SCl Radio Buttons and Check Boxes In the bad old days, there was a. .parate catalog for every SAS 6.08 provides support for SCL radio buttons and check ,operating system that the application supported. There was aI~ boxes that minimize user confusion and input errors. They also a separate group of extemaJ SAS prograr1Js, or .S files, for each redt.lce the SCL code size, as less error trapping lines need to be operating system, which had to be individually tweaked to run on written. each operati~ system. In the bad old days, version,control was a major' hassle. as 50,000 lines of code had to-be overhauled during the port for each_ operating system. This allocated most programmer resources into maintaining the large ,volume of code, rather than developing new code and modules. 606 Figure 4 In the bad old days, existing equipment was poorly integrated. Some machines were in constant use, while others sat in SAs/Connect Configura6on isolation, only rarely used. SAS jobs took forever to execute on PCs and overworked mainframes. and no one was ever happy. Remote MVS Mainframe Remote UNIX Workstation There Must Be A Better Way There are several solutions to the bad old days. One possible solution is to perform all development in UNIX, and use X-. tenninals to run SAS from UNIX wor1 Remote Data Processing SASICONNECT: A Solution for Multi-Platform Data processing can take place on a remote host through the Development Problems remote SUbmission capabilities of SASICONNECT. Data can be transferred back and forth between the local environment and the As has been mentioned. a large corporate computing environment remote host through PROC DOWNLOAD and PROC UPLOAD. will typically combine mainframes. mini computers, UNIX workstations, IBM personal computers, and Macintoshes. In • Local Display of Output many systems, these platforms are poor1y integrated and often All output created through the remote submission is displayed under-utilized. The goal of a networked environment is to locally. This means that the lOG file and lST file are updated to integrate all of these systems into an efficient and coherent reflect the results of the remote submission. whole. Although the technology to integrate system s through remote processing and connectivity technology has been Connection to Multiple Hosts available for years, it has not been practically usable until very SAS/CONNECT can provide multiple concurrent connections. recenUy. SAs/CONNECT provides a straightlorward means to The Batch Jobs program in LOAW contains an environment field integrate systems into a more efficient whole. that lets the user specify different execution environments for each step of the batch job. SAS/CONNECT provicie~ support for numerous network access methods. To use SAs/CONNECT you must have a supported Better Code Management communications access method installed on all intended Since SAS/CONNECT supports remote processing, there is no plaHonns. We have tested SAs/CONNECT with an ETHERNET need to keep and maintain code on remote hosts. Rather. the card and Novell's LAN WorKplace for DOS®. code can all be kept and maintained on the local environment. This makes multi~platform development significantly easier and The role of SAS/CONNECT in integrating system resources is better to manage. pictured in Figure 4. In this sample configuration. SASICONNECT is usad to link a local PC running SAS 6.08 for Better Use of Available Machine Resources Windows to an MVS mainframe and to a group of UNIX By supporting remote processing, SASfCONNECT integrates workstations. available machine resources to provide a more efficient data analysis solution. 607 SAS, SAS/AF, SAS/CONNECT, and SAS Multi-Engine Conclusion Architecture are the registered trademarks of SAS Institute Inc., Cary, NC, USA. Multi·platform development is a difficult process that is made much easier through the use of SAS porting facilities, SAS Multi MS-DOS is the trademarK of Microsoft. Engine Architecture, and SAS/CONNECT. Despite some limitations, SAs/CONNECT is a superior product that can be used Sun, SunOS, Sofaris, and OpenWindows are the registered to solve many multi-platform development problems. trademarks of Sun Microsystems. Inc. SAs/CONNECT helps to concentrate development resources, while supporting more users through network connectivity. All SPARC bademar1 LAN WorKplace for DOS is the registered trademarK of Novell. 608