Multivendor Architecture -- Supporting Feature Rich Platforms with a Uniformly Architected System

Multivendor Architecture (MY A TM) is the foundation of the cross-platfonn portability and interoperability of the SAS® System, Version 6. This architecrure provides customers with hardware independence and a flexible implementation. In 1993 alone, the Institute's MV A strategy delivered the SAS System on an unprecedented thirteen operating systems. However, with continued divergent development of operating system software in areas such as the graphical user interface, graphic and print driver managers, hypertext viewers, editors, and other services that are integral to the operating system, users are faced with a dilemma: They can develop wellintegrated applications on individual operating systems, or concentrate on applications that are less well integrated into specific platfonns, but port easily and unifonnly to many operating environments. This paper discusses proposed enhancements to the Institute's Multivendor Architecrure that will help bridge the gap between a well-integrated platfonn application and a highly portable application. The audience is invited to participate in a panel discussion of customer direction as related to this topic with Institute Host Division Managers inunediately following this paper. INTRODUCTION What is MV A today? To understand what MV A is today, we must look back at the trends in the computer industry during it's inception in early 1985. In the computer hardware industry, a shake out of major players was beginning. Traditional mini computer markets began to shrink as economically priced Unix RISC based workstations and servers became increasingly more powerful. ffiM PCs, PC clones, and Apple Macintosh computers began to quickly proliferate across desktops. Intel and Motorola began demonstrating processor perfonnance increases at a clip of 200% per year. Mainftame computing was still near it's all time peak. These conditions in the hardware industry generated a sense of uncertainty for managers responsible for outlining their organization's computing architecture. In the software industry, a transition of languages used in the professional computing arena had begun. The C programming language was quickly 1335 replacing Pascal and Assembler as the choice for professional applications development, and this shift in programming style was spurred on by the increasing popularity of Unix. This was a time of change. MIS decision makers and end users needed x-ray vision and a crystal ball to chan the course for their operations for the rest of the decade. What was certain, was that no longer would a company's infonnation technology be provided by a single hardware vendor. Customers were looking for software solutions and tools that insulated them from hardware platfonns. This background provided the basis for MV A. At that time, the SAS System was just being fmished converting from the PL/I programming language to the C programming language. The SAS System was architected to be portable across all hard ware and operating systems plarfonns supported by the Institute at the present time as well as taking into consideration platfonns that were on the horizon. The Institute's development teams went about researching and designing the building of a large application program that could be portable across all hardware and operating system platfonns. Much research was spawned on the design of virtual operating systems. The dominant goal of Version 6 was portability across all platfonns. Emphasis was placed on portability of software, featUre set, data sets and catalogs. Subsystems for developing a portable application program were designed with the intent that these subsystems would be developed optimally on each platfonn. Below are listed the fIrst subsystems creating the foundation of MY A: Subsystems desigued for platform dependent optimizations • Memory and Task Management • File I/O, data set, catalog, and external fIles • Dynamic Executable Loading • Display Manager primitives • Native machine code generator • Communications Management • Miscellaneous services Another set of subsystems were designed portably with no intent that the subsystem would be replaced or signifIcantly enhanced on the target platfonn. These subsystems were considered to execute and perfonn identically as possible across all SAS platfonns. These subsystems in effect, addressed end user issues where there were no standards. Subsystems designed for platform independence with little or no platform optimizations • Help System Display and Authoring • Graphics Device Drivers, Printers and Plotters • Print Management using Fonns • Portable Full Screen Display Manager • Message Text Manager A major decision that in retrospect has proven to be very strategic and important, was made that the entire SAS System would be ported and available on all SAS supponed platfonns. At that time, this was a courageous decision. Critics claimed that an application developed on and for the mainframe market could not be poned and run on a PC with only 640k of memory. However, this was accomplished as a result of the MY A design. The resulting SAS System Version 6, was a product that perfonned well, and was in fact portable across all supponed platfonns. SAS applications were portable across platforms and data could be moved across platfonns. Hardware independence through portable software was achieved. Portability can be measured in many factors. The SAS System was and still is portable in all the following ways: • Portable C source code 1336 • Data set and catalogs are portable • Procedure feature set and syntax • Data Step feature set and syntax Constantly at odds, however, was the competing goals of the SAS portable feature set compatibility and the uniqueness and advantages that each platfonn provided. Although MY A provided for the "hooks" to take advantage of platfonn specific features, the rate of platfonn evolution was astounding in the early 1990s. The workstation market including Unix, PCs, and MACs grew stronger each year. These platfonns sought to create usability standards where none had either existed or been accepted before. It became clear at the lnstirute that the MY A design needed to evolve to suppon platfonn optimized subsystems that had previously been considered platfonn portable.