DB2

From MidrangeWiki
Revision as of 22:39, 12 June 2005 by Al Mac (talk | contribs)
Jump to: navigation, search

DB2 400 is the database built in to OS/400.

See IBM site on DB2. http://www.ignite400.org/html/iSeriesWebSites.htm

Also see DB2 article at [Wikopedia http://en.wikipedia.org/wiki/DB2]

Data Base Access

It is normally accessed directly from a high level language such as SQL, or a Data Base Tool like Query.

New files may be added via

Adding a new file is like adding a new program, only conceptually more simple minded. We use a structured language to define the layout, and if logical file include what contents in what sequence, then we compile the object.

The 400 comes with various commands that permit us to dump or display the contents of files various ways.

Terminology Structure Navigation

  • Physical File = SQL Table
    • Individual Records = SQL Row
    • Fields of the File = SQL Column
  • In addition to the Data Records
  • Format
    • A File can have more than one Format, or layout, but not all programming languages can cope with this
  • Members
    • A file can have more than one collection of records, all sharing the same file characteristics, but with a different name, and not all programming languages can cope with this
    • Many BPCS Files use Members to organize different aspects of some application
      • Customer Orders, RMAs (Returns from Customers0, "Quotes" where there is a tentative order not yet approved ... they all use same file name layout, but a different member for function
  • Logical File = Access Path = SQL Logical View
    • Some languages and tools have choice of pointing to one logical, or one big view (ignore logical boundaries)
    • RPG thinks it is accessing the whole file, but we control which member via the CLP that calls the RPG Program, at run time

SOURCE - PHYSICAL FILE

Typically we edit source code using PDM / SEU / Code/400 which can also be used to access other types of physical files.

  • Source code for programs is in a physical file in which each individual program is in a different member of that file
  • IBM recommends source file name structure Q language SRC but we are not bound by this
    • QBASSRC for BASIC programs
    • QCBLSRC for COBOL programs
    • QCLBLLESRC for ILE COBOL programs
    • QCLSRC for CLP programs
    • QCMDSRC for Command Definition
    • Communication Files
    • QDKTSRC diskette device file specifications
      • Who writes for diskette these days?
    • QDDSSRC for DDS used in defining file layouts, physical and logical files, printer output files, interactive screen displays
      • We might want to organize the specifications into a separate Q file for files, help screens, interactive screens, prompt screens, report output, even though they might all be created with DDS
        • QFMTSRC for Format and Reformat
        • Menus might be in QMNUSRC
    • Menus might be in QSDASRC
    • QPASSRC for Pascal
    • QPL1SRC for PL/1
    • QPNLSRC is where BPCS places UIM source for panels such as HELP and MENUs
    • QRJXSRC for RJE Remote Job Entry specifications
    • QRPGSRC for RPG/400 programs
    • QRPGLESRC for ILE RPG 4
    • QS36SRC for S/36 Environment
    • QTAPSRC for tape device file specifications
      • We not need this for backup because the act of copying 400 files to some other name or place, the external description travels along with the data records
    • QTBLSRC for Translate Tables
    • QTXTSRC for documentation
    • QUDSSRC for IDU applications
  • The format of each Q*SRC contains the rules for the language involved
    • How big a line #
    • remember date last change
    • actual data
    • programming language source of rules
      • This gets us automatic syntax checking during interactive program editing

Organizing software on the 400 this way, makes it easier to import similar code. The Data records of each program member can be treated like data by the program compiler, and various 400 languages and database tools

Mapping Relationships

  • DSPDBR = Display, or Print, Data Base relations
    • ie. what are all the logicals that point at this physical file
  • DSPPGRMEF = Display, or Print, all the objects accessed by this program
    • not a pretty picture
    • We can send output of *ALL programs to an *OUTFILE then access it via Query or programming language
      • also not a pretty picture if different programs access same physical file using different logicals

In addition to what comes with IBM ADT Tool Set, there are Third Party sources of tools to help us make sense of what all is in our data base and software collection, and what their interrelationships are

Temporary Access Paths

There is a performance hit when we have many different logical views of a physical file, since they all have to be updated when there is any change to the data contents of the physical file.

If there are logical views that are rarely needed, consider wiping them out after the run that needs them, and adding them at beginning of same run, so they are not a drain on the system when not needed.

Features of DB2

Compared to how files could be structured and accessed on prior IBM and other platforms, DB2 had several revolutionary features that added to the potential programming power of the 400.

Some DB2 capabilities, that we take for granted today on the 400, may have been available on S/38 but not on S/36 SSP.

  • DB2 defines data at the system level
    • This minimizes / eliminates data redundancy
    • Any number of different 400 languages and database tools can access the same file layout, without needing definition within that software
  • DB2 supports
    • Data Sharing
    • Referential Integrity
    • Triggers
    • Stored Procedures

External Definition

Before the invention of this data base reality, we could only use Internal Definition of files. That means each and every program had to have its own layout of a file, and any dumps of the file showed all the data contigous, not breaking it up into meaningful fields. Forget about being able to access the data with programs like SQL.

With Internal Definition, each program only needed to define the fields it was going to use, which meant there might not be any one place to go for the complete layout of a file.

With External Definition, part of the DB2 file structure is the whole story on the file and its field layout, which can be accessed by any programming language in the IBM family.

Internal Definition is still supported, and we can use it in a program to break an External Definition field down into smaller sub-fields such as through a Data Structure.

Internal Definition

Prior to External Definition, tthe Traditional way to define files was by describing them within Programs.

Each program would have line for line record layout.

This ran risks of mistakes by too many cooks, and was a more tedious way to program, except via /COPY layout from some library of layouts.

If there was a change needed in file layout, like adding another field, we had to change it in every program, and compile all of them. Even though most programs not using THAT new field, there was the issue of conflict with definition of size of file.

20-30 % of COBOL code was this stuff, with a lesser impact on RPG

External Advantages

By having Data Definition as part of the file itself, in addition to the Dta Records, each program need only identify the file, and the layout gets sucked into the program at compile time.

Move or copy an object, and its Descriptive Part moves along with the Data Records.

Retrieved from "https://wiki.midrange.com/index.php?title=DB2&oldid=5438"