DOCSLIB.ORG

Transaction Processing System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Transaction processing system From Wikipedia, the free encyclopedia (Redirected from Transaction processing systems) It has been suggested that this article or section be merged into Transaction processing. (Discuss) Proposed since November 2012. Transaction processing is a style of computing that divides work into individual, indivisible operations, called transactions.[1] Atransaction processing system (TPS) or transaction server is a software system, or software/hardware combination, that supports transaction processing. Contents [hide] 1 History 2 List of transaction processing systems 3 Processing types o 3.1 Batch processing o 3.2 Real-time processing o 3.3 Time-sharing o 3.4 Transaction processing 4 Transaction processing system features o 4.1 Performance o 4.2 Continuous availability o 4.3 Data integrity o 4.4 Ease of use o 4.5 Modular growth 5 Databases and files o 5.1 Data warehouse o 5.2 Backup procedures . 5.2.1 Recovery process . 5.2.2 Types of back-up procedures . 5.2.2.1 Grandfather- father-son . 5.2.2.2 Partial backups . 5.2.3 Updating in a batch . 5.2.4 Updating in real-time 6 See also 7 References 8 Further reading [edit]History One of the first transaction processing systems was American Airline SABRE system, which became operational in 1960. Designed to process up to 83,000 transactions a day, the system ran on two IBM 7090 computers. SABRE was migrated to IBM System/360computers in 1972, and became an IBM product first as Airline control Program (ACP) and later as Transaction Processing Facility (TPF). In addition to airlines TPF is used by large banks, credit card companies, and hotel chains. The Hewlett-Packard NonStop system (formerly Tandem NonStop) was a hardware and software system designed for Online Transaction Processing (OLTP) introduced in 1976. The systems were designed for transaction processing and provided an extreme level of availability and data integrity. [edit]List of transaction processing systems • IBM Transaction Processing Facility (TPF) - 1960. Unlike most other transaction processing systems TPF is a dedicated operating system for transaction processing on IBM System z mainframes. Originally Airline Control Program (ACP). • IBM Information Management System (IMS) - 1966. A joint hierarchical database and information management system with extensive transaction processing capabilities. Runs on OS/360 and successors. • IBM Customer Information Control System (CICS) - 1969. A transaction manager designed for rapid, high-volume online processing, CICS originally used standard system datasets, but now has a connection to IBM's DB/2 relational database system. Runs onOS/360 and successors and DOS/360 and successors, IBM AIX, VM, and OS/2. Non-mainframe versions are called TXSeries. • Tuxedo - 1980s. Transactions for Unix, Extended for Distributed Operations developed by AT&T Corporation, now owned by Oracle Corporation. Tuxedo is a cross-platform TPS. • UNIVAC Transaction Interface Package (TIP) - 1970s. A transaction processing monitor for UNIVAC 1100/2200 series computers.[2] • Burroughs Corporation supported transaction processing capabilities in its MCP operating systems. As of 2012 UNISYS ClearPath Enterprise Servers include Transaction Server, "an extremely flexible, high- performance message and application control system."[3] • Digital Equipment Corporation (DEC) Application Control and Management System (ACMS) - 1985. "Provides an environment for creating and controlling online transaction processing (OLTP) applications on the VMS operating system."[4][5] Runs on VAX/VMSsystems. • Digital Equipment Corporation (DEC) Message Control System (MCS-10) for PDP-10 TOPS- 10 systems. • Honeywell Multics Transaction Processing. Feature (TP) - 1979.[6] • Transaction Management eXecutive (TMX) was NCR Corporation's proprietary transaction processing system running on NCR Tower 5000-series systems. This system was used mainly by financial institutions in the 1980s and 1990s. • Hewlett-Packard NonStop system - 1976. NonStop is an integrated hardware and software system specifically designed for transaction processing. Originally from Tandem Computers. • Transarc Encina - 1991.[7] Transarc was purchased by IBM in 1994. Encina was discontinued as a product and folded into IBM'sTXSeries.[8] Encina support was discontinued in 2006. [edit]Processing types Transaction processing is distinct from other computer processing models — batch processing, time-sharing, and real-time processing.[9] [edit]Batch processing Main article: Batch processing Batch processing is execution of a series of programs (jobs) on a computer without manual intervention. Several transactions, called abatch are collected and processed at the same time. The results of each transaction are not immediately available when the transaction is being entered;[1] there is a time delay. [edit]Real-time processing Main article: Real-time computing "Real time systems attempt to guarantee an appropriate response to a stimulus or request quickly enough to affect the conditions that caused the stimulus."[9] Each transaction in real-time processing is unique; it is not part of a group of transactions. [edit]Time-sharing Main article: Time-sharing Time sharing is the sharing of a computer system among multiple users, usually giving each user the illusion that they have exclusive control of the system. The users may be working on the same project or different projects, but there are usually few restrictions on the type of work each user is doing. [edit]Transaction processing Main article: Transaction processing Transaction processing systems also attempt to provide predictable response times to requests, although this is not as critical as for real-time systems. Rather than allowing the user to run arbitrary programs as time- sharing, transaction processing allows only predefined, structured transactions. Each transaction is usually short duration and the processing activity for each transaction is programmed in advance. [edit]Transaction processing system features The following features are considered important in evaluating transaction processing systems.[9] [edit]Performance Fast performance with a rapid response time is critical. Transaction processing systems are usually measured by the number of transactions they can process in a given period of time. [edit]Continuous availability The system must be available during the time period when the users are entering transactions. Many organizations rely heavily on their TPS; a breakdown will disrupt operations or even stop the business. [edit]Data integrity The system must be able to handle hardware or software problems without corrupting data. Multiple users must be protected from attempting to change the same piece of data at the same time, for example two operators cannot sell the same seat on an airplane. [edit]Ease of use Often users of transaction processing systems are casual users. The system should be simple for them to understand, protect them from data-entry errors as much as possible, and allow them to easily correct their errors. [edit]Modular growth The system should be capable of growth at incremental costs, rather than requiring a complete replacement. It should be possible to add, replace, or update hardware and software components without shutting down the system. [edit]Databases and files The storage and retrieval of data must be accurate as it is used many times throughout the day. A database is a collection of data neatly organized, which stores the accounting and operational records in the database. Databases are always protective of their delicate data, so they usually have a restricted view of certain data. Databases are designed using hierarchical, network or relational structures; each structure is effective in its own sense. • Hierarchical structure: organizes data in a series of levels, hence why it is called hierarchical. Its top to bottom like structure consists of nodes and branches; each child node has branches and is only linked to one higher level parent node. • Network structure: Similar to hierarchical, network structures also organizes data using nodes and branches. But, unlike hierarchical, each child node can be linked to multiple, higher parent nodes. • Relational structure: Unlike network and hierarchical, a relational database organizes its data in a series of related tables. This gives flexibility as relationships between the tables are built. A relational structure. A hierarchical structure. A network structure. The following features are included in real time transaction processing systems: • Good data placement: The database should be designed to access patterns of data from many simultaneous users. • Short transactions: Short transactions enables quick processing. This avoids concurrency and paces the systems. • Real-time backup: Backup should be scheduled between low times of activity to prevent lag of the server. • High normalization: This lowers redundant information to increase the speed and improve concurrency, this also improves backups. • Archiving of historical data: Uncommonly used data are moved into other databases or backed up tables. This keeps tables small and also improves backup times. • Good hardware configuration: Hardware must be able to handle many users and provide quick response times. [edit]Data warehouse Main article: Data warehouse A data warehouse is a database that collects information from different sources. When it's gathered in real-time transactions it can be used for analysis efficiently if it's stored in a
Recommended publications
  • Rainblock: Faster Transaction Processing in Public Blockchains

    Rainblock: Faster Transaction Processing in Public Blockchains

    RainBlock: Faster Transaction Processing in Public Blockchains Soujanya Ponnapalli1, Aashaka Shah1, Souvik Banerjee1, Dahlia Malkhi2, Amy Tai3, Vijay Chidambaram1,3, and Michael Wei3 1University of Texas at Austin, 2Diem Association and Novi Financial, 3VMware Research Abstract Metric No state State: 10M Ratio We present RAINBLOCK, a public blockchain that achieves Time taken to mine txs (s) 1047 6340 6× " high transaction throughput without modifying the proof-of- # Txs per block 2150 833 2.5× # work consensus. The chief insight behind RAINBLOCK is that Tx throughput (txs/s) 28.6 4.7 6× # while consensus controls the rate at which new blocks are added to the blockchain, the number of transactions in each Table 1: Impact of system state on blockchain throughput. block is limited by I/O bottlenecks. Public blockchains like This table shows the throughput of Ethereum with proof-of- Ethereum keep the number of transactions in each block low work consensus when 30K txs are mined using three miners, so that all participating servers (miners) have enough time to in two scenarios: first, there are no accounts on the blockchain, process a block before the next block is created. By removing and in the second, 10M accounts have been added. Despite the I/O bottlenecks in transaction processing, RAINBLOCK al- no other difference, tx throughput is 6× lower in the second lows miners to process more transactions in the same amount scenario; we trace this to the I/O involved in processing txs. of time. RAINBLOCK makes two novel contributions: the RAIN- BLOCK architecture that removes I/O from the critical path of processing transactions (txs), and the distributed, multi- Bitcoin [1] and Ethereum, process only tens of transactions versioned DSM-TREE data structure that stores the system per second, limiting their applications [33, 65].
  • Not ACID, Not BASE, but SALT a Transaction Processing Perspective on Blockchains

    Not ACID, Not BASE, but SALT a Transaction Processing Perspective on Blockchains

    Not ACID, not BASE, but SALT A Transaction Processing Perspective on Blockchains Stefan Tai, Jacob Eberhardt and Markus Klems Information Systems Engineering, Technische Universitat¨ Berlin fst, je, [email protected] Keywords: SALT, blockchain, decentralized, ACID, BASE, transaction processing Abstract: Traditional ACID transactions, typically supported by relational database management systems, emphasize database consistency. BASE provides a model that trades some consistency for availability, and is typically favored by cloud systems and NoSQL data stores. With the increasing popularity of blockchain technology, another alternative to both ACID and BASE is introduced: SALT. In this keynote paper, we present SALT as a model to explain blockchains and their use in application architecture. We take both, a transaction and a transaction processing systems perspective on the SALT model. From a transactions perspective, SALT is about Sequential, Agreed-on, Ledgered, and Tamper-resistant transaction processing. From a systems perspec- tive, SALT is about decentralized transaction processing systems being Symmetric, Admin-free, Ledgered and Time-consensual. We discuss the importance of these dual perspectives, both, when comparing SALT with ACID and BASE, and when engineering blockchain-based applications. We expect the next-generation of decentralized transactional applications to leverage combinations of all three transaction models. 1 INTRODUCTION against. Using the admittedly contrived acronym of SALT, we characterize blockchain-based transactions There is a common belief that blockchains have the – from a transactions perspective – as Sequential, potential to fundamentally disrupt entire industries. Agreed, Ledgered, and Tamper-resistant, and – from Whether we are talking about financial services, the a systems perspective – as Symmetric, Admin-free, sharing economy, the Internet of Things, or future en- Ledgered, and Time-consensual.
  • Operating Systems

    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,
  • What Is a Database Management System? What Is a Transaction

    What Is a Database Management System? What Is a Transaction

    What is a Database? Collection of data central to some enterprise Overview of Databases and Essential to operation of enterprise Transaction Processing Contains the only record of enterprise activity An asset in its own right Chapter 1 Historical data can guide enterprise strategy Of interest to other enterprises State of database mirrors state of enterprise Database is persistent 2 What is a Database Management What is a Transaction? System? When an event in the real world changes the A Database Management System (DBMS) state of the enterprise, a transaction is is a program that manages a database: executed to cause the corresponding change in the database state Supports a high-level access language (e.g. With an on-line database, the event causes the SQL). transaction to be executed in real time Application describes database accesses using A transaction is an application program that language. with special properties - discussed later - to DBMS interprets statements of language to guarantee it maintains database correctness perform requested database access. 3 4 What is a Transaction Processing Transaction Processing System System? Transaction execution is controlled by a TP monitor s DBMS database n o i Creates the abstraction of a transaction, t c a analogous to the way an operating system s n a r creates the abstraction of a process t DBMS database TP monitor and DBMS together guarantee the special properties of transactions TP Monitor A Transaction Processing System consists of TP monitor, databases, and transactions 5 6 1 System
  • SQL Server Protection Whitepaper

    SQL Server Protection Whitepaper

    SQL Server Protection Whitepaper Contents 1. Introduction ..................................................................................................................................... 2 Documentation .................................................................................................................................................................. 2 Licensing ............................................................................................................................................................................... 2 The benefits of using the SQL Server Add-on ....................................................................................................... 2 Requirements ...................................................................................................................................................................... 2 2. SQL Protection overview ................................................................................................................ 3 User databases ................................................................................................................................................................... 3 System databases .............................................................................................................................................................. 4 Transaction logs ................................................................................................................................................................
  • How to Conduct Transaction Log Analysis for Web Searching And

    How to Conduct Transaction Log Analysis for Web Searching And

    Search Log Analysis: What is it; what’s been done; how to do it Bernard J. Jansen School of Information Sciences and Technology The Pennsylvania State University 329F IST Building University Park, Pennsylvania 16802 Email: [email protected] Abstract The use of data stored in transaction logs of Web search engines, Intranets, and Web sites can provide valuable insight into understanding the information-searching process of online searchers. This understanding can enlighten information system design, interface development, and devising the information architecture for content collections. This article presents a review and foundation for conducting Web search transaction log analysis. A methodology is outlined consisting of three stages, which are collection, preparation, and analysis. The three stages of the methodology are presented in detail with discussions of goals, metrics, and processes at each stage. Critical terms in transaction log analysis for Web searching are defined. The strengths and limitations of transaction log analysis as a research method are presented. An application to log client-side interactions that supplements transaction logs is reported on, and the application is made available for use by the research community. Suggestions are provided on ways to leverage the strengths of, while addressing the limitations of, transaction log analysis for Web searching research. Finally, a complete flat text transaction log from a commercial search engine is available as supplementary material with this manuscript. Introduction Researchers have used transaction logs for analyzing a variety of Web systems (Croft, Cook, & Wilder, 1995; Jansen, Spink, & Saracevic, 2000; Jones, Cunningham, & McNab, 1998; Wang, 1 of 42 Berry, & Yang, 2003). Web search engine companies use transaction logs (also referred to as search logs) to research searching trends and effects of system improvements (c.f., Google at http://www.google.com/press/zeitgeist.html or Yahoo! at http://buzz.yahoo.com/buzz_log/?fr=fp- buzz-morebuzz).
  • Transaction Processing Monitors

    Transaction Processing Monitors

    Chapter 24: Advanced Transaction Processing ! Transaction-Processing Monitors ! Transactional Workflows ! High-Performance Transaction Systems ! Main memory databases ! Real-Time Transaction Systems ! Long-Duration Transactions ! Transaction management in multidatabase systems 1 Database System Concepts 24.1 ©Silberschatz, Korth and Sudarshan Transaction Processing Monitors ! TP monitors initially developed as multithreaded servers to support large numbers of terminals from a single process. ! Provide infrastructure for building and administering complex transaction processing systems with a large number of clients and multiple servers. ! Provide services such as: ! Presentation facilities to simplify creating user interfaces ! Persistent queuing of client requests and server responses ! Routing of client messages to servers ! Coordination of two-phase commit when transactions access multiple servers. ! Some commercial TP monitors: CICS from IBM, Pathway from Tandem, Top End from NCR, and Encina from Transarc 2 Database System Concepts 24.2 ©Silberschatz, Korth and Sudarshan 1 TP Monitor Architectures 3 Database System Concepts 24.3 ©Silberschatz, Korth and Sudarshan TP Monitor Architectures (Cont.) ! Process per client model - instead of individual login session per terminal, server process communicates with the terminal, handles authentication, and executes actions. ! Memory requirements are high ! Multitasking- high CPU overhead for context switching between processes ! Single process model - all remote terminals connect to a single server process. ! Used in client-server environments ! Server process is multi-threaded; low cost for thread switching ! No protection between applications ! Not suited for parallel or distributed databases 4 Database System Concepts 24.4 ©Silberschatz, Korth and Sudarshan 2 TP Monitor Architectures (Cont.) ! Many-server single-router model - multiple application server processes access a common database; clients communicate with the application through a single communication process that routes requests.
  • Chapter 10 Introduction to Batch Files

    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.
  • Uni Hamburg – Mainframe Summit 2010 Z/OS – the Mainframe Operating System

    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.
  • High-Performance Transaction Processing in SAP HANA

    High-Performance Transaction Processing in SAP HANA

    High-Performance Transaction Processing in SAP HANA Juchang Lee1, Michael Muehle1, Norman May1, Franz Faerber1, Vishal Sikka1, Hasso Plattner2, Jens Krueger2, Martin Grund3 1SAP AG 2Hasso Plattner Insitute, Potsdam, Germany, 3eXascale Infolab, University of Fribourg, Switzerland Abstract Modern enterprise applications are currently undergoing a complete paradigm shift away from tradi- tional transactional processing to combined analytical and transactional processing. This challenge of combining two opposing query types in a single database management system results in additional re- quirements for transaction management as well. In this paper, we discuss our approach to achieve high throughput for transactional query processing while allowing concurrent analytical queries. We present our approach to distributed snapshot isolation and optimized two-phase commit protocols. 1 Introduction An efficient and holistic data management infrastructure is one of the key requirements for making the right deci- sions at an operational, tactical, and strategic level and is core to support all kinds of enterprise applications[12]. In contrast to traditional architectures of database systems, the SAP HANA database takes a different approach to provide support for a wide range of data management tasks. The system is organized in a main-memory centric fashion to reflect the shift within the memory hierarchy[2] and to consistently provide high perfor- mance without prohibitively slow disk interactions. Completely transparent for the application, data is orga- nized along its life cycle either in column or row format, providing the best performance for different workload characteristics[11, 1]. Transactional workloads with a high update rate and point queries can be routed against a row store; analytical workloads with range scans over large datasets are supported by column oriented data struc- tures.
  • Approaches to Optimize Batch Processing on Z/OS

    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.
  • Parallel Processing Here at the School of Statistics

    Parallel Processing Here at the School of Statistics

    Parallel Processing here at the School of Statistics Charles J. Geyer School of Statistics University of Minnesota http://www.stat.umn.edu/~charlie/parallel/ 1 • batch processing • R package multicore • R package rlecuyer • R package snow • grid engine (CLA) • clusters (MSI) 2 Batch Processing This is really old stuff (from 1975). But not everyone knows it. If you do the following at a unix prompt nohup nice -n 19 some job & where \some job" is replaced by an actual job, then • the job will run in background (because of &). • the job will not be killed when you log out (because of nohup). • the job will have low priority (because of nice -n 19). 3 Batch Processing (cont.) For example, if foo.R is a plain text file containing R commands, then nohup nice -n 19 R CMD BATCH --vanilla foo.R & executes the commands and puts the printout in the file foo.Rout. And nohup nice -n 19 R CMD BATCH --no-restore foo.R & executes the commands, puts the printout in the file foo.Rout, and saves all created R objects in the file .RData. 4 Batch Processing (cont.) nohup nice -n 19 R CMD BATCH foo.R & is a really bad idea! It reads in all the objects in the file .RData (if one is present) at the beginning. So you have no idea whether the results are reproducible. Always use --vanilla or --no-restore except when debugging. 5 Batch Processing (cont.) This idiom has nothing to do with R. If foo is a compiled C or C++ or Fortran main program that doesn't have command line arguments (or a shell, Perl, Python, or Ruby script), then nohup nice -n 19 foo & runs it.