DOCSLIB.ORG

DB2 Standards and Guidelines (PDF)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
DB2 Standards and Guidelines (PDF) CENTERS for MEDICARE AND MEDICAID SERVICES DATABASE ADMINISTRATION DB2 STANDARDS 9/1/2020 http://www.cms.hhs.gov/DBAdmin/downloads/DB2StandardsandGuidelines.pdf 9/1/2020 CMS DB2 Standards and Guidelines i OVERVIEW ................................................................................................................................................ 1 DB2 DATABASE DESIGN STANDARDS .................................................................................................. 1 1.1 DB2 Design Overview ......................................................................................................... 1 1.2 Databases ............................................................................................................................... 2 1.3 Tablespaces ............................................................................................................................ 3 1.4 Tables ....................................................................................................................................... 6 1.5 Columns ................................................................................................................................... 7 1.6 Referential Constraints (Foreign Keys) ........................................................................ 9 1.7 Table Check Constraints .................................................................................................. 11 1.8 Unique Constraints ............................................................................................................ 12 1.9 ROWID .................................................................................................................................... 13 1.10 Identity Columns ............................................................................................................ 15 1.11 Sequence Objects ........................................................................................................... 16 1.12 Views ................................................................................................................................... 17 1.13 Indexes ............................................................................................................................... 18 1.14 Table Alias ......................................................................................................................... 19 1.15 Synonyms .......................................................................................................................... 20 1.16 Stored Procedures .......................................................................................................... 21 1.17 User Defined Functions ................................................................................................ 22 1.18 User Defined Types ........................................................................................................ 22 1.19 Triggers .............................................................................................................................. 23 1.20 LOBs..................................................................................................................................... 23 1.21 Buffer Pools ....................................................................................................................... 24 1.22 Capacity Planning ........................................................................................................... 25 1.23 Space Requests ............................................................................................................... 25 APPLICATION PROGRAMMING ............................................................................................................... 26 2.1 Data Access (SQL) ............................................................................................................. 26 2.2 Application Recovery......................................................................................................... 28 2.3 Program Preparation ......................................................................................................... 28 2.3.1 DB2 Package..................................................................................................................... 28 2.3.2 DB2 Plan ............................................................................................................................. 29 2.3.3 Explains .............................................................................................................................. 29 2.4 DB2 Development Tools .................................................................................................. 29 NAMING STANDARDS ............................................................................................................................ 30 3.1.1 Standard Naming Format for DB2 Objects ........................................................... 30 3.1.2 Application Identifiers ................................................................................................... 36 3.1.3 Environment Identifiers ............................................................................................... 36 3.1.4 Obsolete Object names ................................................................................................ 37 3.2 Image Copy Dataset Names .......................................................................................... 38 3.3 DB2 Subsystem Names ................................................................................................... 40 3.4 Production Library Names ............................................................................................... 40 3.5 Test Library Names ........................................................................................................... 41 3.6 Utility Job Names ............................................................................................................... 41 3.7 DB2/ORACLE Naming Issues ......................................................................................... 42 SECURITY ................................................................................................................................................ 43 4.1 RACF Groups ........................................................................................................................ 43 4.1.1 DB2 Owner Groups ........................................................................................................... 43 4.1.2 Role Based Access Groups ............................................................................................. 43 ii CMS DB2 Standards and Guidelines 9/1/2020 4.1.3 DB2 specific RACF Groups ............................................................................................. 44 4.2 DB2 Security Administration .......................................................................................... 44 4.2.1 Development .................................................................................................................... 44 4.2.2 Integration ........................................................................................................................ 46 4.2.3 Validation.......................................................................................................................... 47 4.2.4 Production ......................................................................................................................... 48 4.3 Accessing DB2 Resources ............................................................................................... 49 4.3.1 Dynamic SQL Applications (SPUFI, SAS, QMF, DB2 Connect, etc.) ............ 50 4.3.2 Static SQL Applications ................................................................................................ 50 4.3.3 Execution Environments .............................................................................................. 50 DATABASE MIGRATION PROCEDURES ................................................................................................. 52 5.1 DB2 Database Migration Overview .............................................................................. 52 5.2 Preliminary Physical Database Design Review........................................................ 53 5.2.1 Pre-Development Migration Review Checklist ..................................................... 54 5.2.2 Development Setup ....................................................................................................... 54 5.3 Pre-Integration Migration Review ................................................................................ 58 5.3.1 Pre-Integration Migration Review Checklist ......................................................... 59 5.4 Pre-Production Migration Review ................................................................................. 61 5.4.1 Pre-Production Migration Review Checklist .......................................................... 62 DATABASE UTILITIES ............................................................................................................................ 64 6.1 CMS Standard DB2 Utilities ............................................................................................ 64 6.2 Restrictions on Utilities with QREPed Tables ........................................................... 65 DATABASE PERFORMANCE MONITORING ...........................................................................................
Load more

Recommended publications
  • Rocket Universe 11 Structural Changes
    Rocket UniVerse 11 Structural Changes What you need to know before you install or upgrade to UniVerse 11 Rocket U2 Technical Support Supplemental Information April 2014 UNV-112-REP-OG-1 Notices Edition Publication date: April 2014 Book number: UNV-112-REP-OG-1 Product version: Rocket UniVerse V11.2 Copyright © Rocket Software, Inc. or its affiliate 1985-2014. All Rights Reserved. Trademarks Rocket is a registered trademark of Rocket Software, Inc. For a list of Rocket registered trademarks go to: www.rocketsoftware.com/about/legal. All other products or services mentioned in this document may be covered by the trademarks, service marks, or product names of their respective owners. Examples This information might contain examples of data and reports. The examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. License agreement This software and the associated documentation are proprietary and confidential to Rocket Software, Inc. or its affiliates, are furnished under license, and may be used and copied only in accordance with the terms of such license. Note: This product may contain encryption technology. Many countries prohibit or restrict the use, import, or export of encryption technologies, and current use, import, and export regulations should be followed when exporting this product. Contact information Website: www.rocketsoftware.com Rocket Software, Inc. Headquarters 77 4th Avenue, Suite 100 Waltham, MA 02451-1468 USA Tel: +1 781 577 4321 Fax: +1 617 630 7100 2 Contacting Global Technical Support If you have current support and maintenance agreements with Rocket Software, you can access the Rocket Customer Portal to report and track a problem, to submit an enhancement request or question, or to find answers in the U2 Knowledgebase.
    [Show full text]
  • A Trusted Mechanised Javascript Specification
    A Trusted Mechanised JavaScript Specification Martin Bodin Arthur Charguéraud Daniele Filaretti Inria & ENS Lyon Inria & LRI, Université Paris Sud, CNRS Imperial College London [email protected] [email protected] d.fi[email protected] Philippa Gardner Sergio Maffeis Daiva Naudžiunien¯ e˙ Imperial College London Imperial College London Imperial College London [email protected] sergio.maff[email protected] [email protected] Alan Schmitt Gareth Smith Inria Imperial College London [email protected] [email protected] Abstract sation was crucial. Client code that works on some of the main JavaScript is the most widely used web language for client-side ap- browsers, and not others, is not useful. The first official standard plications. Whilst the development of JavaScript was initially just appeared in 1997. Now we have ECMAScript 3 (ES3, 1999) and led by implementation, there is now increasing momentum behind ECMAScript 5 (ES5, 2009), supported by all browsers. There is the ECMA standardisation process. The time is ripe for a formal, increasing momentum behind the ECMA standardisation process, mechanised specification of JavaScript, to clarify ambiguities in the with plans for ES6 and 7 well under way. ECMA standards, to serve as a trusted reference for high-level lan- JavaScript is the only language supported natively by all major guage compilation and JavaScript implementations, and to provide web browsers. Programs written for the browser are either writ- a platform for high-assurance proofs of language properties. ten directly in JavaScript, or in other languages which compile to We present JSCert, a formalisation of the current ECMA stan- JavaScript.
    [Show full text]
  • BCL: a Cross-Platform Distributed Data Structures Library
    BCL: A Cross-Platform Distributed Data Structures Library Benjamin Brock, Aydın Buluç, Katherine Yelick University of California, Berkeley Lawrence Berkeley National Laboratory {brock,abuluc,yelick}@cs.berkeley.edu ABSTRACT high-performance computing, including several using the Parti- One-sided communication is a useful paradigm for irregular paral- tioned Global Address Space (PGAS) model: Titanium, UPC, Coarray lel applications, but most one-sided programming environments, Fortran, X10, and Chapel [9, 11, 12, 25, 29, 30]. These languages are including MPI’s one-sided interface and PGAS programming lan- especially well-suited to problems that require asynchronous one- guages, lack application-level libraries to support these applica- sided communication, or communication that takes place without tions. We present the Berkeley Container Library, a set of generic, a matching receive operation or outside of a global collective. How- cross-platform, high-performance data structures for irregular ap- ever, PGAS languages lack the kind of high level libraries that exist plications, including queues, hash tables, Bloom filters and more. in other popular programming environments. For example, high- BCL is written in C++ using an internal DSL called the BCL Core performance scientific simulations written in MPI can leverage a that provides one-sided communication primitives such as remote broad set of numerical libraries for dense or sparse matrices, or get and remote put operations. The BCL Core has backends for for structured, unstructured, or adaptive meshes. PGAS languages MPI, OpenSHMEM, GASNet-EX, and UPC++, allowing BCL data can sometimes use those numerical libraries, but are missing the structures to be used natively in programs written using any of data structures that are important in some of the most irregular these programming environments.
    [Show full text]
  • A Soft Linen Emulsion Rate Intelligent Control System Based on the Domain Interpolation Algorithm with Self Adjusting
    JOURNAL OF SOFTWARE, VOL. 6, NO. 8, AUGUST 2011 1429 A Soft Linen Emulsion Rate Intelligent Control System Based on the Domain Interpolation Algorithm with Self Adjusting Xiao Ying Jinggangshan University / school of Electronic and Information Engineering, Ji’an, Jiangxi ,China 343009 [email protected] Peng Xuange Jinggangshan University / school of Electronic and Information Engineering, Ji’an, Jiangxi ,China 343009 [email protected] Abstract—A soft linen emulsion rate intelligent control linen and ramie is called as soft linen, including system based on the domain interpolation algorithm with mechanical soft linen, fuel, wet and storage. The purpose self adjusting is introduced. In the hemp textile industry, is to enable fiber loose, soft, surface lubrication, remove soft linen deal processes can directly affect its following some impurities and then fermented by the heap storage process. We take the lead to use the fuzzy control method to improve the fiber spin ability, then carding and applied in soft linen emulsion rate of Intelligent Control System. In the research process, the improvement of spinning can be carried out. This process quality has the product quality is not satisfied by basic fuzzy control direct impact on the following process, such as the method. By improving the algorithm, combined advanced quality of spinning and weaving. interpolation algorithm into fuzzy decision process, that The references show that the world, especially experience rule set has no restriction to access control list, Southeast Asia, in hemp textile the soft linen processes enhanced the flexibility of the method, and obtain fine are used the same fall behind technology model, that is enough fuzzy control table under the same rules.
    [Show full text]
  • Powerconnect 3448 User's Guide
    Dell™ PowerConnect™ 34XX Systems User’s Guide Notes, Notices, and Cautions NOTE: A NOTE indicates important information that helps you make better use of your computer. NOTICE: A NOTICE indicates either potential damage to hardware or loss of data and tells you how to avoid the problem. CAUTION: A CAUTION indicates a potential for property damage, personal injury, or death. ____________________ Information in this document is subject to change without notice. © 2005 Dell Inc. All rights reserved. Reproduction in any manner whatsoever without the written permission of Dell Inc. is strictly forbidden. Trademarks used in this text: Dell, Dell OpenManage, the DELL logo, and PowerConnect are trademarks of Dell Inc. Microsoft and Windows are registered trademarks of Microsoft Corporation. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell Inc. disclaims any proprietary interest in trademarks and trade names other than its own. May 2005 Rev A01 Contents 1 Introduction System Description . 21 PowerConnect 3424 . 21 PowerConnect 3424P . 21 PowerConnect 3448 . 22 PowerConnect 3448P . 22 Stacking Overview . 22 Understanding the Stack Topology . 23 Stacking Failover Topology . 23 Stacking Members and Unit ID. 23 Removing and Replacing Stacking Members . 24 Exchanging Stacking Members . 25 Switching from the Stack Master to the Backup Stack Master. 27 Features Overview. 28 Power over Ethernet . 28 Head of Line Blocking . 28 Flow Control Support (IEEE 802.3X) . 28 Back Pressure Support . 28 Virtual Cable Testing (VCT). 28 MDI/MDIX Support . 29 Auto Negotiation . 29 MAC Address Supported Features . 29 Layer 2 Features .
    [Show full text]
  • Automated Fortran–C++ Bindings for Large-Scale Scientific Applications
    Automated Fortran–C++ Bindings for Large-Scale Scientific Applications Seth R Johnson HPC Methods for Nuclear Applications Group Nuclear Energy and Fuel Cycle Division Oak Ridge National Laboratory ORNL is managed by UT–Battelle, LLC for the US Department of Energy github.com/swig-fortran Overview • Introduction • Tools • SWIG+Fortran • Strategies • Example libraries 2 Introduction 3 How did I get involved? • SCALE (1969–present): Fortran/C++ • VERA: multiphysics, C++/Fortran • MPACT: hand-wrapped calls to C++ Trilinos 4 Project background • Exascale Computing Project: at inception, many scientific app codes were primarily Fortran • Numerical/scientific libraries are primarily C/C++ • Expose Trilinos solver library to Fortran app developers: ForTrilinos product 5 ECP: more exascale, less Fortran Higher-level { }Fortran ECP application codes over time (credit: Tom Evans) 6 Motivation • C++ library developers: expand user base, more F opportunities for development and follow-on funding • Fortran scientific app developers: use newly exposed algorithms and tools for your code C • Multiphysics project integration: in-memory coupling of C++ physics code to Fortran physics code • Transitioning application teams: bite-size migration from Fortran to C++ C++ 7 Tools 8 Wrapper “report card” • Portability: Does it use standardized interoperability? • Reusability: How much manual duplication needed for new interfaces? • Capability: Does the Fortran interface have parity with the C++? • Maintainability: Do changes to the C++ code automatically update
    [Show full text]
  • Metal C Programming Guide and Reference
    z/OS Version 2 Release 3 Metal C Programming Guide and Reference IBM SC14-7313-30 Note Before using this information and the product it supports, read the information in “Notices” on page 159. This edition applies to Version 2 Release 3 of z/OS (5650-ZOS) and to all subsequent releases and modifications until otherwise indicated in new editions. Last updated: 2019-02-15 © Copyright International Business Machines Corporation 1998, 2017. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents List of Figures...................................................................................................... vii List of Tables........................................................................................................ ix About this document.............................................................................................xi Who should read this document................................................................................................................. xi Where to find more information..................................................................................................................xi z/OS Basic Skills in IBM Knowledge Center.......................................................................................... xi How to read syntax diagrams......................................................................................................................xi How to send your comments to IBM......................................................................xv
    [Show full text]
  • Programming in Java
    Introduction to Programming in Java An Interdisciplinary Approach Robert Sedgewick and Kevin Wayne Princeton University ONLINE PREVIEW !"#$%&'(')!"*+,,,- ./01/23,,,0425,67 Publisher Greg Tobin Executive Editor Michael Hirsch Associate Editor Lindsey Triebel Associate Managing Editor Jeffrey Holcomb Senior Designer Joyce Cosentino Wells Digital Assets Manager Marianne Groth Senior Media Producer Bethany Tidd Senior Marketing Manager Michelle Brown Marketing Assistant Sarah Milmore Senior Author Support/ Technology Specialist Joe Vetere Senior Manufacturing Buyer Carol Melville Copyeditor Genevieve d’Entremont Composition and Illustrations Robert Sedgewick and Kevin Wayne Cover Image: © Robert Sedgewick and Kevin Wayne Page 353 © 2006 C. Herscovici, Brussels / Artists Rights Society (ARS), New York Banque d’ Images, ADAGP / Art Resource, NY Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trade- marks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed in initial caps or all caps. The interior of this book was composed in Adobe InDesign. Library of Congress Cataloging-in-Publication Data Sedgewick, Robert, 1946- Introduction to programming in Java : an interdisciplinary approach / by Robert Sedgewick and Kevin Wayne. p. cm. Includes index. ISBN 978-0-321-49805-2 (alk. paper) 1. Java (Computer program language) 2. Computer programming. I. Wayne, Kevin Daniel, 1971- II. Title. QA76.73.J38S413 2007 005.13’3--dc22 2007020235 Copyright © 2008 Pearson Education, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher.
    [Show full text]
  • Draft ANSI Smalltalk Standard
    NCITS J20 DRAFT December, 1997 of ANSI Smalltalk Standard revision 1.9 Draft American National Standard for Information Systems - Programming Languages - Smalltalk Notice This is a draft proposed American National Standard. As such, this is not a completed standard. The Technical Committee may modify this document as a result of comments received during public review and its approval as a standard. Permission is granted to members of NCITS, its technical committees, and their associated task groups to reproduce this document for the purposes of NCITS standardization activities without further permission, provided this notice is included. All other rights are reserved. Any commercial or for-profit reproduction is strictly prohibited. NCITS J20 DRAFT December, 1997 ii of ANSI Smalltalk Standard revision 1.9 Copyright Copyright 1997 National Committee for Information Technology Standards Permission is granted to duplicate this document for the purpose of reviewing the draft standard. NCITS J20 DRAFT December, 1997 iii of ANSI Smalltalk Standard revision 1.9 Table of Contents Page FORWARD vi 1. GOALS AND SCOPE .................................................................................................................... 5 2. CONFORMING IMPLEMENTATIONS AND PROGRAMS .................................................. 7 3. THE SMALLTALK LANGUAGE ............................................................................................... 8 3.1 COMPUTATIONAL MODEL OF SMALLTALK EXECUTION................................................................
    [Show full text]
  • A Meta-Semantic Language for Smart Component-Adapters
    New Jersey Institute of Technology Digital Commons @ NJIT Dissertations Electronic Theses and Dissertations Spring 5-31-2000 A meta-semantic language for smart component-adapters Leon K. Jololian New Jersey Institute of Technology Follow this and additional works at: https://digitalcommons.njit.edu/dissertations Part of the Computer Sciences Commons Recommended Citation Jololian, Leon K., "A meta-semantic language for smart component-adapters" (2000). Dissertations. 406. https://digitalcommons.njit.edu/dissertations/406 This Dissertation is brought to you for free and open access by the Electronic Theses and Dissertations at Digital Commons @ NJIT. It has been accepted for inclusion in Dissertations by an authorized administrator of Digital Commons @ NJIT. For more information, please contact [email protected]. Copyright Warning & Restrictions The copyright law of the United States (Title 17, United States Code) governs the making of photocopies or other reproductions of copyrighted material. Under certain conditions specified in the law, libraries and archives are authorized to furnish a photocopy or other reproduction. One of these specified conditions is that the photocopy or reproduction is not to be “used for any purpose other than private study, scholarship, or research.” If a, user makes a request for, or later uses, a photocopy or reproduction for purposes in excess of “fair use” that user may be liable for copyright infringement, This institution reserves the right to refuse to accept a copying order if, in its judgment,
    [Show full text]
  • Functions in C
    Functions in C Fortran 90 has three kinds of units: a program unit, subroutine units and function units. In C, all units are functions. For example, the C counterpart to the Fortran 90 program unit is the function named main: #include <stdio.h> main () /* main */ f float w, x, y, z; int i, j, k; w = 0.5; x = 5.0; y = 10.0; z = x + y * w; i = j = k = 5; printf("x = %f, y = %f, z = %f n", x, y, z); printf("i = %d, j = %d, k = %dnn", i, j, k); /* main */ n g Every C program must have a function named main; it’s the func- tion where the program begins execution. C also has a bunch of standard library functions, which are functions that come predefined for everyone to use. 1 Standard Library Functions in C1 C has a bunch of standard library functions that everyone gets to use for free. They are analogous to Fortran 90’s intrinsic functions, but they’re not quite the same. Why? Because Fortran 90’s intrinsic functions are built directly into the language, while C’s library functions are not really built into the language as such; you could replace them with your own if you wanted. Here’s some example standard library functions in C: Function Return Type Return Value #include file printf int number of characters written stdio.h Print (output) to standard output (the terminal) in the given format scanf int number of items input stdio.h Scan (input) from standard input (the keyboard) in the given format isalpha int Boolean: is argument a letter? ctype.h isdigit int Boolean: is argument a digit? ctype.h strcpy char [ ] string containing copy string.h Copy a string into another (empty) string strcmp int comparison of two strings string.h Lexical comparison of two strings; result is index in which strings differ: negative value if first string less than second, positive if vice versa, zero if equal sqrt float square root of argument math.h pow float 1st argument raised to 2nd argument math.h 1 Brian W.
    [Show full text]
  • An Extensible Programrning Environment for Modula-3%
    An Extensible Programrning Environment for Modula-3% Mick Jordan’ Abstract 2 Goals This paper describes the design and implementation of The long term objective was to build a practical envi- a practical programming environment for the Modula-3 ronment to support large scale software development in programming language. The environment is organised Modula-3. Initially, the environment would contain only a around an extensible intermediate representation of pro- basic set of well integrated tools such as a compiler, linker grams and makes extensive use of reusable components. and debugger, but would be capable of supporting real The environment is implemented in Modula-3 and exploits projects on a variety of systems. In the longer term ad- some of the novel features of the language. ditional tools such as code browsers, code analysers, and improvements like smart recompilation would be added, building on the basic environment. In this paper, we 1 Introduction are more concerned with how tools are constructed and combined than with the exact details of their functionality The successof a programming language owes much to its or interface to users of the environment. The idea is that, associatedprogramming environment, especially to the set of tools which enable the construction and modification of if the construction of new tools is made easy enough, programs. W5th a new language there is trade-off between new and powerful tools will appear routinely. Important producing an implementation quickly and in providing a sub-goals for the environment were as follows: rich and powerful set of tools. Choosing the first approach typically results in low quality, poorly integrated tools.
    [Show full text]