DOCSLIB.ORG

Operating Systems WT 2019/20

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Operating Systems WT 2019/20 Operating Systems WT 2019/20 Abridged History of Operating Systems Something to Ponder What is an Operating System? try to come up with a definition of what the term operating system means. Discuss your findings amongst yourselves. Operating Systems 2 Operating System Definition My attempt: An operating system is a program that runs and orchestrates other programs, based on a set of optimization criteria. Operating Systems 5 Hardware and Software Hardware Development Operating System Development Operating Systems 6 The First Computer Q: What was the first computer? Operating Systems 7 First Computers ● 1801: Power loom driven by wooden punch cards ● 1822: Steam- driven analytical engine by Charles Babbage ● Mechanical decimal stored ‐program computer, programmable by punch cards, support for calculation and conditional statements ● Remained unbuilt; Based on concepts, Ada Byron later invented subroutines and loops as programming concepts ● 1890: U.S. census supported by Hollerith desk - punch card reader, counting units, wall of dial indicators ● Built by Tabulating Machine Company, which eventually became International Business Machines ● Invented the idea of output punch cards independent from Babbage Operating Systems 8 First Computers ● 1944: Harvard Mark I developed in partnership between Harvard and IBM (ballistic firing tables) ● First programmable digital computer made in the U.S. ● Constructed of switches, relays, rotating shafts, clutches ● Grace Hopper found the first computer bug, invented the predecessor of COBOL and the first compiler ● 1941: Konrad Zuse completed the work on the Z3 ● First programmable electromechanical computer ● Punch film for program and data (lack of paper) ● Mapping of Boolean algebra to relays, developed independently from original Shannon work ● Plankalkül – programming language Operating Systems 9 Von Neumann Architecture ● 1946: ENIAC as first fully electronic computer in the U.S. ● No program memory, re-wiring for each program ● EDVAC: Revolutionary extension with a stored program computer concept by John von Neumann ● Memory contains both the program and the data ● Introduction of a general purpose computer concept Operating Systems 10 Serial Processing ● Computers from 1940 to 1955 were able to perform serial processing ● Programs for the machine (relays, vacuum tubes) written in assembly language ● Console with display lights, switches, punch card reader / plugboard, printer ● Re-wiring or punch card reading necessary for filling the program memory ● Program had complete control of the machine for the entire run-time ● Manual reservation, user either finished early (wasted time) or could not debug their problem ● Long setup time - Job may involve running the compiler program first and feeding in the output again Operating Systems 11 1st Idea: Batch Processing ● A job control language (JCL) operates the monitor application ● Instructions about the compiler to use, data to work on etc. (Fortran prefix $) ● Early version of system calls ● Monitor needed to switch between itself and the application ● Resident monitor parts always in memory ● Demands on hardware: memory protection, timer, privileged instructions for I/O ● User mode vs. monitor mode (system mode, kernel mode, supervisor mode) Operating Systems 13 2nd Idea: Multiprogramming ● Batch processing increases utilization, but jobs still need to wait for I/O operations ● Idea: Load multiple jobs into memory at the same time ● While one is waiting for I/O results, switch to another one ● Multiplexing of resources between a set of jobs became a basic monitor / operating system task -> multi-programming or multi-tasking ● Goal: Maximize CPU utilization Operating Systems 14 2nd Idea: Multiprogramming Operating Systems 15 2nd Idea: Multiprogramming ● Multiprogramming begets interactivity ● Idea: add dedicated job that is always loaded and processes user input (“terminal”) ● Time Sharing Option (TSO) on IBM Mainframe ● Decouples the user from the processing ● But: multiprogramming is cooperative → terminal is unresponsive while the machine is occupied Operating Systems 16 3rd Idea: Preemption / Time Sharing ● Users started to demand interaction with their program, e.g. for retry on errors ● Perform multi-tasking, but act like the machine is exclusively used ● Advent of time-sharing / preemptive multi-tasking systems ● Goal: Minimize single user response time ● Extension of multi-programming to multiple interactive (non-batch) jobs ● Preemptive multi-tasking became a single user demand in modern times ● Leave one application running while starting another one ● Pure batch processing systems still exist: TPM, SAP R/3, HPC Operating Systems 17 Time Sharing – CTSS & MULTICS ● Compatible Time-Sharing System (CTSS) ● Operating system developed at MIT, first for the IBM 7094 in 1961 (32.768 36bit words memory) ● Program always loaded to start at the location of the 5000th word ● System clock generated interrupts roughly every 0.2 seconds ● At each clock interrupt, the system regained control and assigned the processor to another user - time slicing ● Parts of the active program that would be overwritten are written to disk ● Other parts remained inactive in the system memory ● Direct successor MULTICS pioneered many modern operating system concepts Operating Systems 18 Time Sharing – CTSS & MULTICS Source Code: ● https://gitlab.hpi.de/osm-teaching/opsys19labs/multics ● https://gitlab.hpi.de/osm-teaching/opsys19labs/ctss … and more Operating Systems 19 Genealogy of Operating Systems 55 IOCS IBSYS https://www.tele-task.de/lecture/video/7083/ 60 CTSS from 49:50 65 DOS/360 OS/360 MULTICS CP/CM5 RSX#!!M 70 TSO UNIX RT#!! CP/M 75 DOS/VSE MVS/370 VM/370 UNIXV.7 VMS !.0 4.1BSD XENIX MS-DOS 1.0 SYSTEM III DR/DOS 80 SUN OS VSE MVS/XA VM/XA SYSTEM V 4.2BSD AIX POSIX MACH "IN 3.0 OS/2 85 AIX/370 OSF/! 4.3BSD VMS 5.4 "IN 3.! SYSTEM V.4 VSE/ESA MVS/ESA VM/ESA 90 AIX/ESA SOLARIS 2 GNU/LINUX 4.4BSD "IN NT OS/390 "IN 9X 95 z/VSE z/VM VMS 7.3 "IN 2000 z/OS 00 GNU/LINUX 2.6 SOLARIS !0 "IN XP WIN Server 200 03 Operating Systems 20 1969 Unnamed PDP-7 operating system 1969 Open source 1971 to 1973 Unix 1971 to 1973 Version 1 to 4 Mixed/shared source 1974 to 1975 Unix Closed source 1974 to 1975 Version 5 to 6 PWB/Unix Genealogy1978 of Unix (simplified) 1978 BSD 1.0 to 2.0 Unix 1979 Version 7 1979 Unix/32V 1980 1980 BSD 3.0 to 4.1 Xenix System III 1981 1.0 to 2.3 1981 1982 1982 Xenix 3.0 1983 BSD 4.2 SunOS 1983 1 to 1.1 System V R1 to R2 1984 SCO Xenix 1984 Unix 1985 Version 8 SCO Xenix 1985 AIX V/286 System V 1986 Unix-like systems BSD 4.3 1.0 R3 HP-UX 1986 SunOS 1.0 to 1.2 Unix 1.2 to 3.0 SCO Xenix 1987 9 and 10 V/386 1987 (last versions HP-UX 1988 BSD 4.3 System V 2.0 to 3.0 1988 from Tahoe R4 1989 Bell Labs) SCO Xenix 1989 BSD Net/1 V/386 BSD 4.3 1990 Reno 1990 BSD Net/2 1991 Linux 0.0.1 1991 SunOS 4 Minix 386BSD 1.x NexTSTEP/ 1992 OPENSTEP HP-UX 1992 1.0 to 4.0 NetBSD 6 to 11 Linux BSD 0.8 to 1.0 1993 SCO UNIX UnixWare 1993 0.95 to 1.2.x 4.4-Lite 3.2.4 1.x to 2.x & 1994 FreeBSD (System V 1994 1.0 to Lite Release 2 R4.2) 1995 2.2.x NetBSD 1995 OpenBSD OpenServer 1.1 to 1.2 1.0 to 2.2 Solaris 1996 5.0 to 5.04 2.1 to 9 1996 1997 1997 NetBSD 1.3 1998 FreeBSD 1998 3.0 to 3.2 Minix OpenServer 1999 Mac OS X AIX 5.0.5 to 5.0.7 1999 2.x Server 2000 3.0-7.2 2000 2001 to 2004 2001 to 2004 Linux 2005 2.x UnixWare 2005 7.x 2006 to 2007 (System V 2006 to 2007 OpenBSD R5) 2.3-6.1 Solaris 2008 Mac OS X, 2008 FreeBSD NetBSD 10 OS X, 3.3-11.x 1.3-7.1 OpenServer HP-UX 2009 macOS 6.x 11i+ 2009 10.0 to 10.12 DragonFly Minix BSD 2010 3.1.0-3.4.0 (Darwin 2010 1.2.1 to 17) 1.0 to 4.8 OpenSolaris 2011 & derivatives 2011 Linux Operating Systems (illumos, etc.) 21 2012 to 2015 2012 to 2015 3.x Solaris 11.0-11.3 2016 Linux 2016 4.x OpenServer 2017 10.x 2017 Unix History https://www.tuhs.org/ Operating Systems 22 Genealogy of Linux https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg (too large for this slide) Operating Systems 23 Genealogy of Operating Systems 55 IOCS IBSYS https://www.tele-task.de/lecture/video/7083/ 60 CTSS from 49:50 65 DOS/360 OS/360 MULTICS CP/CM5 RSX#!!M 70 TSO UNIX RT#!! CP/M 75 DOS/VSE MVS/370 VM/370 UNIXV.7 VMS !.0 4.1BSD XENIX MS-DOS 1.0 SYSTEM III DR/DOS 80 SUN OS VSE MVS/XA VM/XA SYSTEM V 4.2BSD AIX POSIX MACH "IN 3.0 OS/2 85 AIX/370 OSF/! 4.3BSD VMS 5.4 "IN 3.! SYSTEM V.4 VSE/ESA MVS/ESA VM/ESA 90 AIX/ESA SOLARIS 2 GNU/LINUX 4.4BSD "IN NT OS/390 "IN 9X 95 z/VSE z/VM VMS 7.3 "IN 2000 z/OS 00 GNU/LINUX 2.6 SOLARIS !0 "IN XP WIN Server 200 03 Operating Systems 24 POSIX ● family of standards for maintaining compatibility between operating systems ● on source code level ● on system tools level ● Specification follows existing UNIX implementations ● committee does not invent functionality Operating Systems 25 Summary Operating System Development intricately tied to: ● Utilization: Cost of Labour vs, Cost of Machine ● Use case – commercial / military / government – still relevant today ● Hardware Development – Operating Systems features required implementation in hardware for efficiency – Hardware advancements required adaption of Operating Systems (e.g.
Load more

Recommended publications
  • 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]
  • Operating Systems
    Operating Systems Interface between User & Computer Hardware Applications Programs Utilities Operating System Hardware Utilities Memory Resident File Access & Control Program Creation Memory Resident File Format Structures o Editors Access Management o Compilers Protection Schemes o Debuggers System Access & Control File Manipulation System-Wide Access o File Manipulation Resource Access o File Deletion Error Detection & Response Mechanism Program Execution Error Detection Link-Loaders Error Correction Run-Time Management Response to Unrecoverable Error I/O Device Access & Control Accounting Storage File Format Structures System Usage Collection Access Management System Performance Tuning Protection Schemes Forecasting Enhancement Requirements Billing Users for Usage Resource Manager O/S KernelKernel I/O Controller Printers, Keyboards, I/O Controller Monitors, Portions of Cameras, the O/S Etc. currently in use Computer Main System Memory Portions of Various I/O Application Devices Programs Currently in use Operating System Data Application Programs I/O Controller Storage Processor Processor Data Processor Processor Operation Allocation of Main Memory is made jointly by both the O/S and Memory Management Hardware O/S controls access to I/O devices by Application Programs O/S controls access to and use of files O/S controls access to and use of the processors, i.e., how much time can be allocated to the execution of a particular Application Program Classification of Operating Systems Interactive O/S Keyboard & Monitor Access to O/S Immediate,
    [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]
  • Adventures with Illumos
    > Adventures with illumos Peter Tribble Theoretical Astrophysicist Sysadmin (DBA) Technology Tinkerer > Introduction ● Long-time systems administrator ● Many years pointing out bugs in Solaris ● Invited onto beta programs ● Then the OpenSolaris project ● Voted onto OpenSolaris Governing Board ● Along came Oracle... ● illumos emerged from the ashes > key strengths ● ZFS – reliable and easy to manage ● Dtrace – extreme observability ● Zones – lightweight virtualization ● Standards – pretty strict ● Compatibility – decades of heritage ● “Solarishness” > Distributions ● Solaris 11 (OpenSolaris based) ● OpenIndiana – OpenSolaris ● OmniOS – server focus ● SmartOS – Joyent's cloud ● Delphix/Nexenta/+ – storage focus ● Tribblix – one of the small fry ● Quite a few others > Solaris 11 ● IPS packaging ● SPARC and x86 – No 32-bit x86 – No older SPARC (eg Vxxx or SunBlades) ● Unique/key features – Kernel Zones – Encrypted ZFS – VM2 > OpenIndiana ● Direct continuation of OpenSolaris – Warts and all ● IPS packaging ● X86 only (32 and 64 bit) ● General purpose ● JDS desktop ● Generally rather stale > OmniOS ● X86 only ● IPS packaging ● Server focus ● Supported commercial offering ● Stable components can be out of date > XStreamOS ● Modern variant of OpenIndiana ● X86 only ● IPS packaging ● Modern lightweight desktop options ● Extra applications – LibreOffice > SmartOS ● Hypervisor, not general purpose ● 64-bit x86 only ● Basis of Joyent cloud ● No inbuilt packaging, pkgsrc for applications ● Added extra features – KVM guests – Lots of zone features –
    [Show full text]
  • Hardware-Driven Evolution in Storage Software by Zev Weiss A
    Hardware-Driven Evolution in Storage Software by Zev Weiss A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Computer Sciences) at the UNIVERSITY OF WISCONSIN–MADISON 2018 Date of final oral examination: June 8, 2018 ii The dissertation is approved by the following members of the Final Oral Committee: Andrea C. Arpaci-Dusseau, Professor, Computer Sciences Remzi H. Arpaci-Dusseau, Professor, Computer Sciences Michael M. Swift, Professor, Computer Sciences Karthikeyan Sankaralingam, Professor, Computer Sciences Johannes Wallmann, Associate Professor, Mead Witter School of Music i © Copyright by Zev Weiss 2018 All Rights Reserved ii To my parents, for their endless support, and my cousin Charlie, one of the kindest people I’ve ever known. iii Acknowledgments I have taken what might be politely called a “scenic route” of sorts through grad school. While Ph.D. students more focused on a rapid graduation turnaround time might find this regrettable, I am glad to have done so, in part because it has afforded me the opportunities to meet and work with so many excellent people along the way. I owe debts of gratitude to a large cast of characters: To my advisors, Andrea and Remzi Arpaci-Dusseau. It is one of the most common pieces of wisdom imparted on incoming grad students that one’s relationship with one’s advisor (or advisors) is perhaps the single most important factor in whether these years of your life will be pleasant or unpleasant, and I feel exceptionally fortunate to have ended up iv with the advisors that I’ve had.
    [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]
  • Chapter 10 Introduction to Batch Files
    Instructor’s Manual Chapter 10 Lecture Notes Introduction to Batch Files Chapter 10 Introduction to Batch Files LEARNING OBJECTIVES 1. Compare and contrast batch and interactive processing. 2. Explain how batch files work. 3. Explain the purpose and function of the REM, ECHO, and PAUSE commands. 4. Explain how to stop or interrupt the batch file process. 5. Explain the function and use of replaceable parameters in batch files. 6. Explain the function of pipes, filters, and redirection in batch files. STUDENT OUTCOMES 1. Use Edit to write batch files. 2. Use COPY CON to write batch files. 3. Write and execute a simple batch file. 4. Write a batch file to load an application program. 5. Use the REM, PAUSE, and ECHO commands in batch files. 6. Terminate a batch file while it is executing. 7. Write batch files using replaceable parameters. 8. Write a batch file using pipes, filters, and redirection. CHAPTER SUMMARY 1. Batch processing means running a series of instructions without interruption. 2. Interactive processing allows the user to interface directly with the computer and update records immediately. 3. Batch files allow a user to put together a string of commands and execute them with one command. 4. Batch files must have the .BAT or .CMD file extension. 5. Windows looks first internally for a command, then for a .COM files extension, then for a .EXE file extension, and finally for a .BAT or .CMD file extension. 6. Edit is a full-screen text editor used to write batch files. 7. A word processor, if it has a means to save files in ASCII, can be used to write batch files.
    [Show full text]
  • Uni Hamburg – Mainframe Summit 2010 Z/OS – the Mainframe Operating System
    Uni Hamburg – Mainframe Summit 2010 z/OS – The Mainframe Operating System Appendix 2 – JES and Batchprocessing Redelf Janßen IBM Technical Sales Mainframe Systems [email protected] © Copyright IBM Corporation 2010 Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 4.0.1 Introduction to the new mainframe Chapter 7: Batch processing and the Job Entry Subsystem (JES) © Copyright IBM Corp., 2010. All rights reserved. Introduction to the new mainframe Chapter 7 objectives Be able to: • Give an overview of batch processing and how work is initiated and managed in the system. • Explain how the job entry subsystem (JES) governs the flow of work through a z/OS system. © Copyright IBM Corp., 2010. All rights reserved. 3 Introduction to the new mainframe Key terms in this chapter • batch processing • procedure • execution • purge • initiator • queue • job • spool • job entry subsystem (JES) • symbolic reference • output • workload manager (WLM) © Copyright IBM Corp., 2010. All rights reserved. 4 Introduction to the new mainframe What is batch processing? Much of the work running on z/OS consists of programs called batch jobs. Batch processing is used for programs that can be executed: • With minimal human interaction • At a scheduled time or on an as-needed basis. After a batch job is submitted to the system for execution, there is normally no further human interaction with the job until it is complete. © Copyright IBM Corp., 2010. All rights reserved. 5 Introduction to the new mainframe What is JES? In the z/OS operating system, JES manages the input and output job queues and data.
    [Show full text]
  • Wdd-Ebook.Pdf
    The illumos Writing Device Drivers Sun Microsystems, Inc. has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more U.S. patents or pending patent applications in the U.S. and in other countries. U.S. Government Rights – Commercial software. Government users are subject to the Sun Microsystems, Inc. standard license agreement and applicable provisions of the FAR and its supplements. This distribution may include materials developed by third parties. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, the Solaris logo, the Java Coffee Cup logo, docs.sun.com, Java, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. or its subsidiaries in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and Sun™ Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements.
    [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]
  • Approaches to Optimize Batch Processing on Z/OS
    Front cover Approaches to Optimize Batch Processing on z/OS Apply the latest z/OS features Analyze bottlenecks Evaluate critical path Alex Louwe Kooijmans Elsie Ramos Jan van Cappelle Lydia Duijvestijn Tomohiko Kaneki Martin Packer ibm.com/redbooks Redpaper International Technical Support Organization Approaches to Optimize Batch Processing on z/OS October 2012 REDP-4816-00 Note: Before using this information and the product it supports, read the information in “Notices” on page v. First Edition (October 2012) This edition applies to all supported z/OS versions and releases. This document created or updated on October 24, 2012. © Copyright International Business Machines Corporation 2012. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . .v Trademarks . vi Preface . vii The team who wrote this paper . vii Now you can become a published author, too! . viii Comments welcome. viii Stay connected to IBM Redbooks . ix Chapter 1. Getting started . 1 1.1 The initial business problem statement. 2 1.2 How to clarify the problem statement . 3 1.3 Process to formulate a good problem statement . 3 1.4 How to create a good business case . 5 1.5 Analysis methodology . 6 1.5.1 Initialization . 6 1.5.2 Analysis. 6 1.5.3 Implementation . 10 Chapter 2. Analysis steps. 13 2.1 Setting the technical strategy . 14 2.2 Understanding the batch landscape . 15 2.2.1 Identifying where batch runs and the available resources . 15 2.2.2 Job naming conventions . 15 2.2.3 Application level performance analysis.
    [Show full text]
  • Managing a VSE Console Under VM from a Remote Location
    BY DAN ASKEW Managing a VSE Console Under VM From a Remote Location hen working remotely, it is sometimes necessary to make changes to the system or talk an W operator through a problem. Using the techniques presented here, you can manage a VSE console under VM. you ever tried to talk an operator through a VSEPROD. You can display the virtual machine name by HAVE problem from a remote site and thought to issuing the following commands. yourself, “If I could only see the console”? As this article will This command redisplays the last 20 lines from partition BG: examine, there are several ways you can do this if you are VSECMD VSEPROD RED 20L,BG running VSE under VM. The first method I will examine allows you to communicate with the VSE con- This command displays the last line from sole in a crude line mode. The other two the console: methods allow you to actually “steal” the VSECMD VSEPROD RED existing console away from the operator. Have you ever tried to This command displays the last 20 METHOD #1 talk an operator through occurrences of EOJ: VSECMD VSEPROD RED 20l,’EOJ’ The first method I tried used a problem from a remote IBM’s VMCF modules supplied by The syntax of these commands is VSE. ICCF Library 59 contains a site and thought to as follows: member named SKVMVSE. The yourself, “If I could only VSECMD (VSE machine name) comments at the beginning of the RED (number of lines (default is member provide you with the installa- see the console”? 1)), (redisplay command) tion instructions.
    [Show full text]