DOCSLIB.ORG

Comparing the SAS System Under OS/2 and Microsoft Windows Which

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

comparing the SAS System under OS/2 and Microsoft Windows Which is right for you? Mark W. Cates SAS Institute Inc. Abstract As we enter into the 1990s, two operating systems are available to enhance productivity forcEersonalcomput­ ers and provide a future platform for PC software users. The two environments, OS/2 • version 1.3 and Microsoft Windows ® 3.0 provide fundamentally the same user interface and similar features, but the underly­ ing operating systems are radically different. Today, corporations large and small are deciding which operat­ ing system should be used in their organizations and for which applications. The platform for more powerful and mission critical applications is clearly OS/2. However, with the introduction and overwhelming accep­ tance of Windows 3.0, supporting DOS compatibility, a graphical user interface compatible with Presentation Manager, and access to extended and virtual memory, a large memory alternative to OS/2 is available. This paper discusses these two environments with respect to the SAS System. The paper presents the advantages and disadvantages of the operating systems, configuration issues, and future directions, with respect to the SAS System. Issues that are particularly important to the SAS System are described in detail. Finally, the implications of the new 32 bit OS/2 version 2.0 are presented. (In this paper, Microsoft Windows 3.0 will be referred to as an operating system. Actual~, Microsoft Windows is a layered operating environment that runs on top of the operating system PC DOS •. For purposes of this paper, the distinction between operating environment and operating system is not important.) SAS release status for OS/2 and Windows Version 6.06 of the SAS System has been in production for OS/2 1.2 and 1.3 Standard and Extended Edition, as well as Microsoft's OEM versions since November 1990. It supports all SAS version 6.06 products and procedures including SAS/ACCESS, SAS/AF, SAS/ASSIST, SAS/BASE, SAS/CONNECT, SAS/ETS, SAS/ FSP, SAS/IML, SAS/GRAPH, SAS/OR, SAS/STAT, and SAS/QC. At SUGI15 in Nashville (March 1990), the Institute announced the planned support for Microsoft Windows version 3.0, starting with the SAS System version 6.07 .. This release is planned for late 1991. Simultaneously, version 6.07 will be released on OS/2 version 1.3. The Institute is committed to both of these operating environments and believe that each environment is strategic to corporations, and thus will provide support for them with future SAS releases. The products released on each environment will be the same. The feature set of the procedures will be identical; the only difference in the releases will be advanced features that one environment may support that the other does not. The SAS catalog file format and the data set file format will be byte for byte identical across the two systems. SAS data sets and catalogs will be easily and immediate­ ly transferrable between the two operating systems by merely using the copy command. Every attempt will be made to support upgrades of the operating system such as Windows 3.1 and upgrades to OS/2 version 1.3. Complete hardware and software requirements for both systems can be obtained by calling Software Sales at the Institute. Comparing OS/2 and Windows with respect to the SAS System Memory management OS/2 version 1.x supports the architectural functions of the Intel 80286 processor which includes accessing up to 16 Meg of physical extended memory, and up to 1 Gigabyte of virtual memory used for segment swapping. OS/2 1.x executes faster on a 80386 or 80486 processor due to the increased processing power but does not take advantage of 32 bit processing or the advanced memory management facilities of the 80386. OS/2 is supported on a 80286 machine, but SAS performance on this processor is obviously marginal. For 393 OS/2 1.2 and 1.3, the SAS System version 6.06 recommends a minimum of 6 Meg of memory and 8 Meg for optimum performance of large applications like SAS/ASSIST and SAS/GRAPH. It Is important to note that problems are only limited by the amount of disk swap space and that adding additional extended memory will normally increase the limits of the system. Unlike SASPC DOS versions using Expanded Memory (EMS), the SAS System may take advantage of all additional extended memory for both executable code and program data. The increased memory available to applications is a substantial benefit provided by OS/2. Compared to PC DOS execution, the SAS System executes faster under OS/2. Although this is contrary to some reports concerning performance comparisons between PC DOS and OS/2, it holds true for SAS because of the performance loss SAS suffered on PC DOS. Under OS/2, SAS does not have to resort to disk intensive code overlays and costly unloading and loading of executable images. Additionally, the code generator that is used to execute data step and procedure code has been improved and optimized for the OS/2 environment. Windows 3.0 runs in three modes: Real mode, Standard mode, and Enhanced mode. Real mode is the native mode of the original IBM PC using an Intel 8088 microprocessor. Original versions of Windows ran in real mode as does PC DOS, and is provided primarily for compatibility of older Window applications. SAS under Windows does not and will not support real mode in any future release, since real mode limits the application to 1 Meg of memory. In Standard mode, Windows requires at least an Intel 80286 with at least 1 Meg of memory, or a 80386 with less than 2 Meg of memory. In this mode, Windows runs in protected mode which means the processor can address up to a maximum of 16 Meg of extended memory if available. Standard mode, however, is limited to the physical available memory. Once this memory is used by applications, Windows memory management will move and discard program segments to attempt to manage the memory. However, swapping. of seg­ ments to disk to obtain virtual memory is not performed in standard mode. Therefore, adding more extended memory up to a maximum of 16 Meg is necessary to increase performance and overcome memory limitations for an application like SAS. Standard mode allows an application to execute faster than Enhanced mode because it does not rely on slower virtual device drivers that Window~,uses in enhanced mode. Enhanced mode requires an Intel 80386 or 80486 processor and at least 2 Meg of .extended memory. This is the most optimal mode for Windows and for power users. In this mode, the processor can once again access up to a maximum of 16 Meg of extended memory. However, Windows memory management takes advantage of the 80386 memory management paging features to "page" in and out 4 k byte blocks. When physical memory has been filled, the paging process begins. Only when all the virtual address space on disk has been used, does Windows discard program segments. (Discarded program segments are required to be reloaded and relocated, and thus discarding is slower than paging.) Enhanced mode can be misleading, especially to power users. A little published fact about Windows enhanced mode is that the virtual paged memory Is limited to approximately four times the amount of physical memory. This is a system limit, not a per task limit. For example, on a machine with 4 Meg of memory, Windows enhanced mode will provide the entire system including all applications running, with an address space up to 16 Meg (4 x 4) of memory, assuming that this amount of disk space is available in either the temporary or permanent swap file. This fact can easily dispell the belief that Windows virtual memory provides the same function and benefit that OS/2 does, just because both run in protected mode. The reason Windows limits the paging to four times physical memory is to prevent a large portion of the physical memory from being used by in-memory page tables. Another advantage of enhanced mode is that Windows uses .the virtual 86 mode of the 80386 processor to allow multiple DOS sessions to run in windows concurrently. This feature is more important for DOS programs. However, running multiple DOS shells can cause instability In DOS because DOS Is not reentrant. SAS version 6.07 will support only standard and enhanced mode. Both modes mode will require at least 6 Meg of memory and additional memory would increase performance. The system will run with less memory in enhanced mode, with a performance degradation. Multitasking and the Security of applications Perhaps the most important distinction between OS/2 and Windows is the method in which multitasking is accomplished. OS/2 is a powerful operating system that supports preemptive, time sliced multithreading 394 and multitasking. For example, there are features in the operating system to support multitasking such as threads, semaphores, signals, priority, separate address space, and a tasked based file system. In addition, OS/2 provides a robust environment for an application like SAS. Applications code and data are protected from being overwritten by other applications. To a large and sophisticated application such as SAS, this is a very important feature of an operating system .. Windows on the other hand, was designed to be compatible with the original Windows programming model of earlier releases, real mode Windows 2.x. Multitasking is not preemptive, but cooperative. Applications must be very well behaved and must yield execution of the application at designated points in order for the system to achieve the appearance of multitasking.
Recommended publications
  • A Microkernel API for Fine-Grained Decomposition

    A Microkernel API for Fine-Grained Decomposition

    A Microkernel API for Fine-Grained Decomposition Sebastian Reichelt Jan Stoess Frank Bellosa System Architecture Group, University of Karlsruhe, Germany freichelt,stoess,[email protected] ABSTRACT from the microkernel APIs in existence. The need, for in- Microkernel-based operating systems typically require spe- stance, to explicitly pass messages between servers, or the cial attention to issues that otherwise arise only in dis- need to set up threads and address spaces in every server for tributed systems. The resulting extra code degrades per- parallelism or protection require OS developers to adopt the formance and increases development effort, severely limiting mindset of a distributed-system programmer rather than to decomposition granularity. take advantage of their knowledge on traditional OS design. We present a new microkernel design that enables OS devel- Distributed-system paradigms, though well-understood and opers to decompose systems into very fine-grained servers. suited for physically (and, thus, coarsely) partitioned sys- We avoid the typical obstacles by defining servers as light- tems, present obstacles to the fine-grained decomposition weight, passive objects. We replace complex IPC mecha- required to exploit the benefits of microkernels: First, a nisms by a simple function-call approach, and our passive, lot of development effort must be spent into matching the module-like server model obviates the need to create threads OS structure to the architecture of the selected microkernel, in every server. Server code is compiled into small self- which also hinders porting existing code from monolithic sys- contained files, which can be loaded into the same address tems. Second, the more servers exist | a desired property space (for speed) or different address spaces (for safety).
  • Openvms Record Management Services Reference Manual

    Openvms Record Management Services Reference Manual

    OpenVMS Record Management Services Reference Manual Order Number: AA-PV6RD-TK April 2001 This reference manual contains general information intended for use in any OpenVMS programming language, as well as specific information on writing programs that use OpenVMS Record Management Services (OpenVMS RMS). Revision/Update Information: This manual supersedes the OpenVMS Record Management Services Reference Manual, OpenVMS Alpha Version 7.2 and OpenVMS VAX Version 7.2 Software Version: OpenVMS Alpha Version 7.3 OpenVMS VAX Version 7.3 Compaq Computer Corporation Houston, Texas © 2001 Compaq Computer Corporation Compaq, AlphaServer, VAX, VMS, the Compaq logo Registered in U.S. Patent and Trademark Office. Alpha, PATHWORKS, DECnet, DEC, and OpenVMS are trademarks of Compaq Information Technologies Group, L.P. in the United States and other countries. UNIX and X/Open are trademarks of The Open Group in the United States and other countries. All other product names mentioned herein may be the trademarks of their respective companies. Confidential computer software. Valid license from Compaq required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.
  • Windows Command Prompt Cheatsheet

    Windows Command Prompt Cheatsheet

    Windows Command Prompt Cheatsheet - Command line interface (as opposed to a GUI - graphical user interface) - Used to execute programs - Commands are small programs that do something useful - There are many commands already included with Windows, but we will use a few. - A filepath is where you are in the filesystem • C: is the C drive • C:\user\Documents is the Documents folder • C:\user\Documents\hello.c is a file in the Documents folder Command What it Does Usage dir Displays a list of a folder’s files dir (shows current folder) and subfolders dir myfolder cd Displays the name of the current cd filepath chdir directory or changes the current chdir filepath folder. cd .. (goes one directory up) md Creates a folder (directory) md folder-name mkdir mkdir folder-name rm Deletes a folder (directory) rm folder-name rmdir rmdir folder-name rm /s folder-name rmdir /s folder-name Note: if the folder isn’t empty, you must add the /s. copy Copies a file from one location to copy filepath-from filepath-to another move Moves file from one folder to move folder1\file.txt folder2\ another ren Changes the name of a file ren file1 file2 rename del Deletes one or more files del filename exit Exits batch script or current exit command control echo Used to display a message or to echo message turn off/on messages in batch scripts type Displays contents of a text file type myfile.txt fc Compares two files and displays fc file1 file2 the difference between them cls Clears the screen cls help Provides more details about help (lists all commands) DOS/Command Prompt help command commands Source: https://technet.microsoft.com/en-us/library/cc754340.aspx.
  • Why Os/2 Failed: Business Mistakes Compounded by Memory Prices

    Why Os/2 Failed: Business Mistakes Compounded by Memory Prices

    Mountain Plains Journal of Business and Economics Volume 10 Issue 1 Article 4 Date Published: 10-1-2009 Why Os/2 Failed: Business Mistakes Compounded By Memory Prices Eric G. Swedin Weber State University Davis Follow this and additional works at: https://openspaces.unk.edu/mpjbt Part of the Business Commons Recommended Citation Swedin, E. G. (2009). Why Os/2 Failed: Business Mistakes Compounded By Memory Prices. Mountain Plains Journal of Business and Economics, 10(1). Retrieved from https://openspaces.unk.edu/mpjbt/ vol10/iss1/4 This Case Study is brought to you for free and open access by OpenSPACES@UNK: Scholarship, Preservation, and Creative Endeavors. It has been accepted for inclusion in Mountain Plains Journal of Business and Economics by an authorized editor of OpenSPACES@UNK: Scholarship, Preservation, and Creative Endeavors. For more information, please contact [email protected]. 36 WHY OS/2 FAILED: BUSINESS MISTAKES COMPOUNDED BY MEMORY PRICES ERIC G. SWEDIN WEBER STATE UNIVERSITY DAVIS ABSTRACT In 2006, IBM ended their support of OS/2, closing the book on an ambitious effort to create a modern operating system for the personal computer. IBM and Microsoft released the OS/2 operating system in December 1987 to replace the primitive DOS with a more sophisticated, preemptive multitasking operating system for personal computers. This article argues that OS/2 failed because of the U.S.-Japan Semiconductor Trade Agreement of 1986, subsequent accusations of DRAM chip dumping by the United States, and the resulting tariffs on Japanese memory chips, led to a memory chip shortage that drove up memory prices.
  • Software Requirements Specification

    Software Requirements Specification

    Software Requirements Specification for Connectome Version 3.0 Prepared by: 1. Jon Schuck 2. Kennan Meyer 3. Nate Bender 4. Sheik Hassan 5. Khaled Alhendi 6. Bairavi Venkatesh 7. Kevin Garrone Senior Design Project Advisor: Mr. Jeff Salvage Fall 2016 to Spring 2017 1 Table of Contents Revision History.............................................................................................................................. 4 1. Introduction ............................................................................................................................. 5 1.1. Purpose ............................................................................................................................. 5 1.2. Overview .......................................................................................................................... 5 1.3. Product Scope ................................................................................................................... 6 1.3.1. In Scope .................................................................................................................... 6 1.3.2. Out of Scope ............................................................................................................. 7 1.4. Definitions ........................................................................................................................ 7 2. Overall Description ................................................................................................................. 9 2.1. Hardware Functions
  • Guidelines for Tools Development and Operating Environments

    Guidelines for Tools Development and Operating Environments

    Managing social, behavioral and economic data and metadata Guidelines for Tools Development and Operating Environments Author/Maintainer Pascal Heus, Open Data Foundation Contributors Jack Gager(Metadata Technology), Jannick Jensen (Danish Data Archive), Herve Lhours (UKDA) Version 2010-08-03 Table of Contents Overview....................................................................................................................................................2 Product Development.................................................................................................................................3 Environment.......................................................................................................................................... 3 Collaborative environment.................................................................................................................... 4 Licensing............................................................................................................................................... 5 Products Guide...........................................................................................................................................8 Overview............................................................................................................................................... 8 Web server software.............................................................................................................................. 8 Rich client Platforms...........................................................................................................................10
  • Fortran Reference Guide

    Fortran Reference Guide

    FORTRAN REFERENCE GUIDE Version 2018 TABLE OF CONTENTS Preface............................................................................................................ xv Audience Description......................................................................................... xv Compatibility and Conformance to Standards............................................................ xv Organization................................................................................................... xvi Hardware and Software Constraints...................................................................... xvii Conventions................................................................................................... xvii Related Publications........................................................................................ xviii Chapter 1. Language Overview............................................................................... 1 1.1. Elements of a Fortran Program Unit.................................................................. 1 1.1.1. Fortran Statements................................................................................. 1 1.1.2. Free and Fixed Source............................................................................. 2 1.1.3. Statement Ordering................................................................................. 2 1.2. The Fortran Character Set.............................................................................. 3 1.3. Free Form Formatting..................................................................................
  • Accessing Windows Applications from Unix and Vice Versa

    Accessing Windows Applications from Unix and Vice Versa

    50-20-42 DATA COMMUNICATIONS MANAGEMENT ACCESSING WINDOWS APPLICATIONS FROM UNIX AND VICE VERSA Raj Rajagopal INSIDE Accessing Windows Applications from an X-Station, Coexistence Options, Windows in an X-Station, Accessing Windows Applications, Accessing UNIX Applications from Windows Desktops, Emulators Migrating from one environment to another takes planning, resources and, most importantly, time (except in very trivial cases). This implies that even if eventually migrating to another environment, one still has to deal with coexistence among environments in the interim. In many com- panies it would make good business sense not to migrate legacy systems at all. Instead, it may be better to develop new systems in the desired en- vironment and phase out the legacy applications. The data created by the legacy applications is important and one must ensure that data can be ac- cessed from a new environment. Coexistence considerations are very im- portant in this case. Coexistence between Windows PAYOFF IDEA NT, UNIX, and NetWare deals with a Some users want applications they develop in number of related issues. One may one environment to execute in other environ- need to access Windows applications ments with very little change. With this approach, they can continue to develop applications with from a UNIX machine or need to ac- the confidence that they will execute in another cess UNIX applications from Win- environment even if the environments change in dows desktops. One may prefer to the future. In applications that can run in both have the same type of desktop (Òan Windows NT and UNIX, this can be accomplished enterprise desktopÓ) for all users and in several ways: be able to access different environ- •use APIs — there are three flavors of this ap- ments.
  • Introduction to Linux on System Z

    Introduction to Linux on System Z

    IBM Linux and Technology Center Introduction to Linux on System z Mario Held IBM Lab Boeblingen, Germany © 2009 IBM Corporation IBM Linux and Technology Center Trademarks The following are trademarks of the International Business Machines Corporation in the United States, other countries, or both. Not all common law marks used by IBM are listed on this page. Failure of a mark to appear does not mean that IBM does not use the mark nor does it mean that the product is not actively marketed or is not significant within its relevant market. Those trademarks followed by ® are registered trademarks of IBM in the United States; all others are trademarks or common law marks of IBM in the United States. For a complete list of IBM Trademarks, see www.ibm.com/legal/copytrade.shtml: *, AS/400®, e business(logo)®, DBE, ESCO, eServer, FICON, IBM®, IBM (logo)®, iSeries®, MVS, OS/390®, pSeries®, RS/6000®, S/30, VM/ESA®, VSE/ESA, WebSphere®, xSeries®, z/OS®, zSeries®, z/VM®, System i, System i5, System p, System p5, System x, System z, System z9®, BladeCenter® The following are trademarks or registered trademarks of other companies. Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
  • Introduction to Unix

    Introduction to Unix

    Introduction to Unix Rob Funk <[email protected]> University Technology Services Workstation Support http://wks.uts.ohio-state.edu/ University Technology Services Course Objectives • basic background in Unix structure • knowledge of getting started • directory navigation and control • file maintenance and display commands • shells • Unix features • text processing University Technology Services Course Objectives Useful commands • working with files • system resources • printing • vi editor University Technology Services In the Introduction to UNIX document 3 • shell programming • Unix command summary tables • short Unix bibliography (also see web site) We will not, however, be covering these topics in the lecture. Numbers on slides indicate page number in book. University Technology Services History of Unix 7–8 1960s multics project (MIT, GE, AT&T) 1970s AT&T Bell Labs 1970s/80s UC Berkeley 1980s DOS imitated many Unix ideas Commercial Unix fragmentation GNU Project 1990s Linux now Unix is widespread and available from many sources, both free and commercial University Technology Services Unix Systems 7–8 SunOS/Solaris Sun Microsystems Digital Unix (Tru64) Digital/Compaq HP-UX Hewlett Packard Irix SGI UNICOS Cray NetBSD, FreeBSD UC Berkeley / the Net Linux Linus Torvalds / the Net University Technology Services Unix Philosophy • Multiuser / Multitasking • Toolbox approach • Flexibility / Freedom • Conciseness • Everything is a file • File system has places, processes have life • Designed by programmers for programmers University Technology Services
  • LECTURE NOTE 5: the MEMORY MANAGEMENT REAL MODE Allows the Microprocessor to Address Only the First 1Mbyte of Memory Even If Its Pentium II Microprocessor

    LECTURE NOTE 5: the MEMORY MANAGEMENT REAL MODE Allows the Microprocessor to Address Only the First 1Mbyte of Memory Even If Its Pentium II Microprocessor

    LECTURE NOTE 5: THE MEMORY MANAGEMENT REAL MODE Allows the microprocessor to address only the first 1Mbyte of memory even if its Pentium II microprocessor. The first 1Mbyte of memory is called either the real mode or conventional memory system. The DOS operating system requires the microprocessor to operate in this mode. It allows application software. Segment and Offset Through the combination of these two, a memory location is accessed in the real mode. All real mode memory address must consist of a segment address plus an offset address. Segment Address Defines the beginning address of any 64k-byte memory segment. Offset Address Sometimes called displacement or relative. Selects any location within the 64k-byte memory segment. It is the distance above the start of the segment. Note: Each segment register is internally appended with a 0H on its right end. The segment address can begin only at a 16-byte boundary, which is called paragraph. Once the beginning address in known, an ending address is known, by adding FFFFH. The code segment register defines the start of the code segment and the instruction pointer to locate the next instruction within the code segment. This combination (CS:IP or CS:EIP) locates the next instruction executed by the microprocessor. Stack data are referenced through the stack segment at the memory location addressed by either the stack pointer (SP/ESP) or the base pointer (BP/EBP). These combinations are referred to as SS:SP (SS:ESP) or SS:BP (SS:EBP). Addressing Modes 1. Register Addressing Mode transfer a copy of a byte or word from the source register or memory location to the destination register or memory location.
  • The Pentium Processor

    The Pentium Processor

    Chapter 7 The Pentium Processor 7–1 The main purpose of registers is to provide a scratch pad so that the processor can keep data on a temporary basis. For example, the processor may keep the procedure return address, stack pointer, instruction pointer, and so on. Registers are also used to keep the data handy so that it can avoid costly memory accesses. Keeping frequently accessed data in registers is a common compiler optimization technique. 7–2 Pentium supports the following three address spaces: 1. Linear address space 2. Physical address space 3. I/O address space (from discussion in Section 1.7) 7–3 In segmented memory organization, memory is partitioned into segments, where each segment is a small part of the memory. In the real mode, each segment of memory is a linear contiguous sequence of up to 64 KB. In the protected mode, it can be up to 4 GB. Pentium supports segmentation largely to provide backward compatibility to 8086. Note that 8086 is a 16-bit processor with 20 address lines. This mismatch between the processor’s 16-bit registers and 20-bit addresses is solved by using the segmented memory architecture. This segmented architecture has been carried over to Pentium. However, in the protected mode, it is possible to consider the entire memory as a single segment; thus, segmentation is completely turned off. 7–4 In the real mode, a segment is limited to 64 KB due to the fact that 16 bits are used to indicate the offset value into a segment. This magic number 16 is due to the 16-bit registers used 8086 processor.