Device Driver Reuse Via Virtual Machines

Total Page:16

File Type:pdf, Size:1020Kb

Device Driver Reuse Via Virtual Machines Device driver reuse via virtual machines A dissertation submitted to the School of Computer Science and Engineering of The University of New South Wales in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Joshua Thomas LeVasseur May 2009 PLEASE TYPE THE UNIVERSITY OF NEW SOUTH WALES Thesis/Dissertation Sheet Surname or Family name: LeVasseur First name: Joshua Other name/s: Abbreviation for degree as given in the University calendar: PhD School: Computer Science and Engineering Faculty: Engineering Title: Device driver reuse via virtual machines Abstract 350 words maximum: (PLEASE TYPE) Device drivers constitute a significant portion of an operating system's source code. The effort to develop a new driver set is a sobering hurdle to the pursuit of novel operating system ventures. A practical solution is to reuse drivers, but this can contradict design goals in a new operating system. We offer a new approach to de\ ice-driver reuse, v\ ith a focus on promoting novel operating-SNStem construction, which insulates the new operating system from the invariants of the reused dri\ ers, while also addressing development effort. Our solution runs the drivers along with their original operating systems inside virtual machines, with some minor reuse infrastructure added to the driver's operating s} stem to interface with the rest of the s) stem. This approach turns the drivers into de-privileged applications of the new operating system, which separates their architectures and reduces cross-influences, and improves system dependability. Virtual machines help reuse drivers, but the> also penalize performance. The known solution for improving virtual machine performance, para-virtualization, modifies the operating system to run on a h} per\ isor, w hich has an enormous cost; substantial development effort, and abandonment of many of v irtualization's benefits such as modularit}. These costs contradict our goals for driver reuse: to reduce development effort, and to easih reuse from a variety of operating s\ stems. Thus we introduce a new approach to constructing virtual machines: pre-virtualization. Our solution combines the performance of para-\ irtualization w ith the modularity of traditional \ irtual machines. We still modify the operating system, but according to a set of principles called soft layering that preserves modularity, and via automation which reduces implementation costs. With pre-virtualization we can easily reuse device drivers. We describe our driver-reuse approach applied to a real system: we run virtual machines on the L4Ka::Pistachio microkernel, with reused Linux drivers. We include an evaluation and demonstrate that we achieve throughput comparable to the native Linux drivers, but with moderately higher CPU and memor} utilization. Additionall>, we describe hov\ to appl) pre- virtualization to multiple hypervisor environments. We include an evaluation of pre-virtualization, and demonstrate that it achieves comparable performance to para-virtualization for both the L4Ka::Pistachio and Xen h\ pervisors, with modularity. Declaration relating to disposition of project thesis/dissertation I hereby grant to the University of New South Wales or its agents the right to archive and to make available my thesis or dissertation in whole or in part in the University libraries in all forms of media, now or here after known, subject to the provisions of the Copyright Act 1968. I retain all property rights, such as patent rights. I also retain the right to use in future works (such as articles or books) all or part of this thesis or dissertation. I also authorise University Microfilms to use the 350 word abstract of my thesis in Dissertation Abstracts International (this is applicable to doctoral theses only). 20 Jully 2009 Signature Witness Date The University recognises that there may be exceptional circumstances requiring restrictions on copying or conditions on use. Requests for restriction for a period of up to 2 years must be made in writing. Requests for a longer period of restriction may be considered in exceptional circumstances and require the approval of the Dean of Graduate Research. FOR OFFICE USE ONLY Date of completion of requirements for Award: C) - c5 - THIS SHEET IS TO BE GLUED TO THE INSIDE FRONT COVER OF THE THESIS Abstract Device drivers constitute a significant portion of an operating system's source code. The effort to develop a new driver set is a sobering hurdle to the pursuit of novel operating system ventures. A practical solution is to reuse drivers, but this can contradict design goals in a new operating system. We offer a new approach to device-driver reuse, with a focus on promoting novel operating-system construc- tion, which insulates the new operating system from the invariants of the reused drivers, while also addressing development effort. Our solution runs the drivers along with their original operating systems inside virtual machines, with some mi- nor reuse infrastructure added to the driver's operating system to interface with the rest of the system. This approach turns the drivers into de-privileged applica- tions of the new operating system, which separates their architectures and reduces cross-influences, and improves system dependability. Virtual machines help reuse drivers, but they also penalize performance. The known solution for improving virtual machine performance, para-virtualization, modifies the operating system to run on a hypervisor, which has an enormous cost: substantial development effort, and abandonment of many of virtualization's bene- fits such as modularity. These costs contradict our goals for driver reuse: to reduce development effort, and to easily reuse from a variety of operating systems. Thus we introduce a new approach to constructing virtual machines: pre-virtualization. Our solution combines the performance of para-virtualization with the modularity of traditional virtual machines. We still modify the operating system, but accord- ing to a set of principles called soft layering that preserves modularity, and via automation which reduces implementation costs. With pre-virtualization we can easily reuse device drivers. We describe our driver-reuse approach applied to a real system: we run vir- tual machines on the L4Ka::Pistachio microkernel, with reused Linux drivers. We include an evaluation and demonstrate that we achieve throughput comparable to the native Linux drivers, but with moderately higher CPU and memory utiliza- tion. Additionally, we describe how to apply pre-virtualization to multiple hyper- visor environments. We include an evaluation of pre-virtualization, and demon- strate that it achieves comparable performance to para-virtualization for both the L4Ka:: Pistachio and Xen hypervisors, with modularity. Originality statement 'I hereby declare that this submission is my own work and to the best of my knowl- edge it contains no materials previously published or written by another person, or substantial proportions of material which have been accepted for the award of any other degree or diploma at UNSW or any other educational institution, except where due acknowledgement is made in the thesis. Any contribution made to the research by others, with whom I have worked at UNSW or elsewhere, is explic- itly acknowledged in the thesis. I also declare that the intellectual content of this thesis is the product of my own work, except to the extent that assistance from others in the project's design and conception or in style, presentation and linguistic expression is acknowledged.' Joshua LeVasseur May 2009 vn vin Copyright and authenticity statements 'I hereby grant the University of New South Wales or its agents the right to archive and to make available my thesis or dissertation in whole or part in the University libraries in all forms of media, now or here after known, subject to the provisions of the Copyright Act 1968. I retain all proprietary rights, such as patent rights. I also retain the right to use in future works (such as articles or books) all or part of this thesis or dissertation. I also authorise University Microfilms to use the 350 word abstract of my thesis in Dissertation Abstract International (this is applicable to doctoral theses only). I have either used no substantial portions of copyright ma- terial in my thesis or I have obtained permission to use copyright material; where permission has not been granted I have applied/will apply for a partial restriction of the digital copy of my thesis or dissertation.' Joshua LeVasseur May 2009 'I certify that the Library deposit digital copy is a direct equivalent of the final officially approved version of my thesis. No emendation of content has occurred and if there are any minor variations in formatting, they are the result of the con- version to digital format.' Joshua LeVasseur May 2009 Acknowledgments My experience working on this project was rewarding and enriching, and a turn- ing point in my life, as all periods of self growth must be. I thank Prof. Gemot Heiser, my supervisor, for relentlessly supporting me throughout the project, and for believing in my ability to succeed. He worked with me on the research and helped guide me through paper writing, and spent considerable time reviewing my thesis and providing feedback. He worked to bring me from the American edu- cational system into the German, which have different requirements for entering a PhD program. He also continued to supervise me from remote, after he transferred to UNSW, while I remained in Germany. 1 thank Prof. Gerhard Goos, of the University of Karlsruhe, for his wonderful advice, guidance, and challenges. He graciously accepted me as a student after Prof. Heiser moved to UNSW. His demanding requests guided me into the person I wanted to become. I enjoyed participating in his PhD seminars, which were important training for paper writing, public speaking, and finally the thesis writing. I thank Prof. Frank Bellosa for accepting me after he become the head of the System Architecture Group in Karlsruhe.
Recommended publications
  • 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).
    [Show full text]
  • IBM VM Recovery Manager DR for Power Systems Version 1.5: Deployment Guide Overview for IBM VM Recovery Manager DR for Power Systems
    IBM VM Recovery Manager DR for Power Systems Version 1.5 Deployment Guide IBM Note Before using this information and the product it supports, read the information in “Notices” on page 195. This edition applies to IBM® VM Recovery Manager DR for Power Systems Version 1.5 and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright International Business Machines Corporation 2020, 2021. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents About this document............................................................................................vii Highlighting.................................................................................................................................................vii Case-sensitivity in VM Recovery Manager DR............................................................................................vii ISO 9000....................................................................................................................................................viii Overview...............................................................................................................1 Concepts...............................................................................................................5 KSYS............................................................................................................................................................. 5 HMC.............................................................................................................................................................
    [Show full text]
  • CA Top Secret for Z/OS Control Options Guide
    CA Top Secret® for z/OS Control Options Guide r15 Ninth Edition This Documentation, which includes embedded help systems and electronically distributed materials (hereinafter referred to as the “Documentation”), is for your informational purposes only and is subject to change or withdrawal by CA at any time. This Documentation is proprietary information of CA and may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. If you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise make available a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy. The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed. TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE.
    [Show full text]
  • Facility/370: Introduction
    File No. S370-20 Order No. GC20-1800=9 IDl\n \/:u+ •• ".1 I\n"n"': ..... ft IDIVI V IIlUQI .Via"'lllIlv Facility/370: Systems Introduction Release 6 PLC 4 This publication introduces VM/370, and is intended for anyone who is interested in VM/370. However, the reader should have a basic understanding of I BM data processing. VM/370 (Virtual Machine Facility/370) is a system control program (SCP) that tailors the resources and capabilities of a single System/370 computer to provide concurrent users their one unique (virtual) machine. VM/370 consists of a Control Program (CP), which manages the real computer, a Conversational Monitor System (CMS), which is a general-purpose conversational time-sharing system that executes in a virtual machine, a Remote Spooling Communications Subsystem (RSCS), which spools files to and from geographically remote locations, and a Interactive Problem Control System (I PCS), which provides problem analysis and management faci I ities. The first section of the publication is an introduction; it describes what VM/370 can do. The second, third, fourth, and fifth sections describe the Control Program, Conversational Monitor System, Remote Spooling Communications Subsystem, and Interactive Problem Control System respectively. The appendixes include information about VM/370 publication-to-audience relationship and VM/370-related publications for CMS users. , This publication is a prerequisite for the VM/370 system library. --...- --- ---.-- ------- ------ --..- --------- -~-y- Page of GC20-1800-9 As Updated Aug 1, 1979 by TNL GN25-0U89 ~b Edition (Karch 1919) This edition (GC20-1800-~ together with Technical Newsletter GN25-0489. dated August 1, 1919, applies to Release 6 PLC 4 (Program Level Change) of IBM Virtual Machine Facility/310 and to all subsequent releases until otherwise indicated in new editions or Technical Newsletters.
    [Show full text]
  • Scalability of VM Provisioning Systems
    Scalability of VM Provisioning Systems Mike Jones, Bill Arcand, Bill Bergeron, David Bestor, Chansup Byun, Lauren Milechin, Vijay Gadepally, Matt Hubbell, Jeremy Kepner, Pete Michaleas, Julie Mullen, Andy Prout, Tony Rosa, Siddharth Samsi, Charles Yee, Albert Reuther Lincoln Laboratory Supercomputing Center MIT Lincoln Laboratory Lexington, MA, USA Abstract—Virtual machines and virtualized hardware have developed a technique based on binary code substitution been around for over half a century. The commoditization of the (binary translation) that enabled the execution of privileged x86 platform and its rapidly growing hardware capabilities have (OS) instructions from virtual machines on x86 systems [16]. led to recent exponential growth in the use of virtualization both Another notable effort was the Xen project, which in 2003 used in the enterprise and high performance computing (HPC). The a jump table for choosing bare metal execution or virtual startup time of a virtualized environment is a key performance machine execution of privileged (OS) instructions [17]. Such metric for high performance computing in which the runtime of projects prompted Intel and AMD to add the VT-x [19] and any individual task is typically much shorter than the lifetime of AMD-V [18] virtualization extensions to the x86 and x86-64 a virtualized service in an enterprise context. In this paper, a instruction sets in 2006, further pushing the performance and methodology for accurately measuring the startup performance adoption of virtual machines. on an HPC system is described. The startup performance overhead of three of the most mature, widely deployed cloud Virtual machines have seen use in a variety of applications, management frameworks (OpenStack, OpenNebula, and but with the move to highly capable multicore CPUs, gigabit Eucalyptus) is measured to determine their suitability for Ethernet network cards, and VM-aware x86/x86-64 operating workloads typically seen in an HPC environment.
    [Show full text]
  • Z/OS ♦ Z Machines Hardware ♦ Numbers and Numeric Terms ♦ the Road to Z/OS ♦ Z/OS.E ♦ Z/OS Futures ♦ Language Environment ♦ Current Compilers ♦ UNIX System Services
    Mainframes The Future of Mainframes Is Now ♦ z/Architecture ♦ z/OS ♦ z Machines Hardware ♦ Numbers and Numeric Terms ♦ The Road to z/OS ♦ z/OS.e ♦ z/OS Futures ♦ Language Environment ♦ Current Compilers ♦ UNIX System Services by Steve Comstock The Trainer’s Friend, Inc. http://www.trainersfriend.com 800-993-8716 [email protected] Copyright © 2002 by Steven H. Comstock 1 Mainframes z/Architecture z/Architecture ❐ The IBM 64-bit mainframe has been named "z/Architecture" to contrast it to earlier mainframe hardware architectures ♦ S/360 ♦ S/370 ♦ 370-XA ♦ ESA/370 ♦ ESA/390 ❐ Although there is a clear continuity, z/Architecture also brings significant changes... ♦ 64-bit General Purpose Registers - so 64-bit integers and 64-bit addresses ♦ 64-bit Control Registers ♦ 128-bit PSW ♦ Tri-modal addressing (24-bit, 31-bit, 64-bit) ♦ Over 140 new instructions, including instructions to work with ASCII and UNICODE strings Copyright © 2002 by Steven H. Comstock 2 z/Architecture z/OS ❐ Although several operating systems can run on z/Architecture machines, z/OS is the premier, target OS ❐ z/OS is the successor to OS/390 ♦ The last release of OS/390 was V2R10, available 9/2000 ♦ The first release of z/OS was V1R1, available 3/2001 ❐ z/OS can also run on G5/G6 and MP3000 series machines ♦ But only in 31-bit or 24-bit mode ❐ Note these terms: ♦ The Line - the 16MiB address limit of MVS ♦ The Bar - the 2GiB limit of OS/390 ❐ For some perspective, realize that 16EiB is... ♦ 8 billion times 2GiB ♦ 1 trillion times 16MiB ❐ The current release of z/OS is V1R4; V1R5 is scheduled for 1Q2004 Copyright © 2002 by Steven H.
    [Show full text]
  • Cisco UCS C240 M4 SFF Rack Server Spec Sheet
    This Product has been discontinued Spec Sheet Cisco UCS C240 M4 High-Density Rack Server (Small Form Factor Disk Drive Model) CISCO SYSTEMS PUBLICATION HISTORY 170 WEST TASMAN DR. SAN JOSE, CA, 95134 REV E.20 MARCH 23, 2021 WWW.CISCO.COM CONTENTS OVERVIEW . 5 DETAILED VIEWS . 6 Chassis Front View . .6 Chassis Rear View . .9 BASE SERVER STANDARD CAPABILITIES and FEATURES . 11 CONFIGURING the SERVER . 15 STEP 1 VERIFY SERVER SKU . 16 STEP 2 SELECT RISER CARDS (OPTIONAL) . 17 STEP 3 SELECT LOCKING SECURITY BEZEL (OPTIONAL) . 18 STEP 4 SELECT CPU(s) . 19 STEP 5 SELECT MEMORY . 21 STEP 6 SELECT RAID CONTROLLERS . 27 RAID Controller Options (internal HDD/SSD support) . 27 Embedded Software RAID . 27 Cisco 12G SAS Modular RAID Controller . 27 SAS HBA (internal HDD/SSD/JBOD support) . 27 SAS HBA (external JBOD support) . 27 RAID Volumes and Groups . 28 STEP 7 SELECT HARD DISK DRIVES (HDDs) or SOLID STATE DRIVES (SSDs) . 39 STEP 8 SELECT SED HARD DISK DRIVES (HDDs) or SOLID STATE DRIVES (SSDs) . 45 STEP 9 SELECT PCIe OPTION CARD(s) . 48 STEP 10 ORDER OPTIONAL NETWORK CARD ACCESSORIES . 53 STEP 11 ORDER GPU CARDS AND GPU POWER CABLES (OPTIONAL) . 58 STEP 12 ORDER POWER SUPPLY . 61 STEP 13 SELECT AC POWER CORD(s) . 62 STEP 14 ORDER TOOL-LESS RAIL KIT AND OPTIONAL REVERSIBLE CABLE MANAGEMENT ARM . 65 STEP 15 SELECT NIC MODE (OPTIONAL) . 66 STEP 16 ORDER A TRUSTED PLATFORM MODULE (OPTIONAL) . 67 STEP 17 ORDER CISCO FLEXIBLE FLASH SD CARD MODULE (OPTIONAL) . 69 STEP 18 ORDER OPTIONAL USB 3.0 DRIVE .
    [Show full text]
  • OS Structures and System Calls
    COS 318: Operating Systems OS Structures and System Calls Kai Li Computer Science Department Princeton University (http://www.cs.princeton.edu/courses/cos318/) Outline Protection mechanisms OS structures System and library calls 2 Protection Issues CPU Kernel has the ability to take CPU away from users to prevent a user from using the CPU forever Users should not have such an ability Memory Prevent a user from accessing others’ data Prevent users from modifying kernel code and data structures I/O Prevent users from performing “illegal” I/Os Question What’s the difference between protection and security? 3 Architecture Support: Privileged Mode An interrupt or exception (INT) User mode Kernel (privileged) mode • Regular instructions • Regular instructions • Access user memory • Privileged instructions • Access user memory • Access kernel memory A special instruction (IRET) 4 Privileged Instruction Examples Memory address mapping Flush or invalidate data cache Invalidate TLB entries Load and read system registers Change processor modes from kernel to user Change the voltage and frequency of processor Halt a processor Reset a processor Perform I/O operations 5 x86 Protection Rings Privileged instructions Can be executed only When current privileged Level (CPR) is 0 Operating system kernel Level 0 Operating system services Level 1 Level 2 Applications Level 3 6 Layered Structure Hiding information at each layer Layered dependency Examples Level N THE (6 layers) . MS-DOS (4 layers) . Pros Level 2 Layered abstraction
    [Show full text]
  • IBM Virtual Machine Facility/370 : Systems Introduction
    GC20-1800-0 IBM Virtual Machine Facility/370 : Systems Introduction The IBM Virtual Machine Facility/370 (VM/370) is a System Control Program (SCP) that has been designed specifically for the IBM System/370. VM/370 manages the IBM System/370 in such a way that mUltiple remote terminal users appear to have a dedicated computing system at their disposal. Within this "virtual machine" the user may run the operaHng system of his choice, subject to the restrictions noted in "Appendix C: VM/370 Restrictions" of this manual. The design of VM/370 is based on the IBM Control Program-67/Cam­ bridge Monitor System (CP-67/CMS) which is executed on an IBM System/360 Model 67. The Conversational Monitor System (CMS) is the major subsystem ofVM/370. CMS provides problem solving and program development services to the user, as well as supporting facilities for a remote user who chooses to run some other operating system in his virtual machine. This manual provides introductory information about the facilities provided by VM/370, and defines the min­ imum equipment configuration necessary for execution. Preface This manual provides introductory information on the IBM Virtual Machine Facility/370 (VM/370) and its associated subsystem, the Conversational Monitor Sys­ tem (CMS), as well as an overview of the purpose and functions of VM/370. It is assumed that the user has a prior knowledge of virtual storage concepts as implemented on the IBM System/370 via dynamic address translation. The reader is referred to Part I of the student text publication Introduction to Virtual Storage in System/370, Order No.
    [Show full text]
  • CA Top Secret R16 Security Target
    CA Top Secret r16 Security Target ST Version: 1.0 August 18, 2017 3333 Warrenville Road Suite 800 Lisle, IL 60532 Prepared By: Cyber Assurance Testing Laboratory 304 Sentinel Drive, Suite 100 Annapolis Junction, MD 20701 Security Target CA Top Secret r16 Table of Contents 1 Security Target Introduction ................................................................................................................. 6 1.1 ST Reference ................................................................................................................................. 6 1.1.1 ST Identification ................................................................................................................... 6 1.1.2 Document Organization ........................................................................................................ 6 1.1.3 Terminology .......................................................................................................................... 7 1.1.4 Acronyms .............................................................................................................................. 8 1.1.5 References ............................................................................................................................. 9 1.2 TOE Reference .............................................................................................................................. 9 1.3 TOE Overview .............................................................................................................................
    [Show full text]
  • CICS Essentials Auditing CICS – a Beginner’S Guide
    CICS Essentials Auditing CICS – A Beginner’s Guide Julie-Ann Williams Mike Cairns Martin Underwood Craig Warren ii CICS ESSENTIALS Foreword by Brian Cummings A thorough Audit Guide for CICS is something that is long overdue. This document provides a wealth of information about CICS, its operations, and its various resources and capabilities along with audit guidelines and recommendations. Various documents on AuditNet and other sources have taken a stab at parts or all of CICS, but are likely not up to date or sufficiently complete. CICS largely remains an environment that holds its mysteries against auditors and security officers alike. The results of poor understanding can lead to dangerous levels of unidentified risk to the applications and sensitive information of entities that use the power of CICS for critical business applications. Unlike any other environment, CICS security implementations fail in the first place because all of the security control is often only focused on transactions. Transactions are many levels of resources removed from the data files and data bases they query or update. In the end, we see the greatest level of security established for the least sophisticated technical users – end business users, and the least security facing the most technically sophisticated – the CICS sub-system programmer and the CICS Application programmer. For example, it is typical to leave FCT resources unsecured and to allow the CICS regions to have total rights to the data sets they access. This condition gives sub-system and application programmers full-reign to use CICS utilities to inherit the CICS regions’ authorities and gain full access to freely browse and update data.
    [Show full text]
  • 402197 350 System Manual.Book
    350 Cable Survey System System Manual Covers DeepView Software Version 5.x.x and Firmware Version 3.7 TSS (International) Ltd 1, Garnett Close Greycaine Industrial Estate Watford, Herts, WD24 7GL Telephone +44 (0)1923 470800 Facsimile +44 (0)1923 470842 24 hr Customer Support +44 (0)7899 665603 e-mail: [email protected] The information in this Manual is subject to change without notice and does not represent a commitment on the part of TSS (International) Ltd Document P/N 402197 Issue 2.4 abcdef January 2008 1 9 9 3 THE QUEEN'S AWARD FOR EXPORT ACHIEVEMENT Contents CAUTIONARY NOTICE This System Manual contains full installation and operating instructions and is an important part of the 350 System. This Manual should remain easily available for use by those who will install, operate and maintain the System. WARNINGS and CAUTIONS Where appropriate, this Manual includes important safety information. Safety infor- mation appears as WARNING and CAUTION instructions. You must obey these instructions: ❐ WARNING instructions alert you to a potential risk of death or injury to users of the 350 System. ❐ CAUTION instructions alert you to the potential risk of damage to the 350 System. For your convenience, the Table of Contents section includes copies of all the WARNING and CAUTION instructions contained in this Manual. Technical Support and contact information TSS (International) Ltd 1 Garnett Close, Greycaine Industrial Estate, Watford, Herts, WD24 7GL Tel: +44 (0)1923 470800 Fax: +44 (0)1923 470842 Out of UK Hours Technical Helpline: +44 (0)7899
    [Show full text]