Difference between revisions of "DB2"
(→Terminology Navigation) |
(→Terminology Structure Navigation: Source) |
||
| Line 30: | Line 30: | ||
** Many [[BPCS]] Files use Members to organize different aspects of some application | ** 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 | *** 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 | + | * 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 code for programs is in a physical file in which each individual program is in a different member of that file | ||
| + | ** QCLSRC for [[CLP]] programs | ||
| + | ** QDDSSRC for [[DDS]] used in defining file layouts, physical and logical files, printer output files, interactive screen displays | ||
| + | ** QPNLSRC is where [[BPCS]] places [[UIM]] source for panels such as HELP and MENUs | ||
| + | ** QRPGSRC for [[RPG/400]] programs | ||
| + | ** QTXTSRC for documentation | ||
== Features of DB2 == | == Features of DB2 == | ||
Revision as of 16:51, 10 June 2005
DB2 400 is the database built in to OS/400.
Also see DB2 article at [Wikopedia http://en.wikipedia.org/wiki/DB2]
Contents
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.
- Physical File = SQL Table
- 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
- Source code for programs is in a physical file in which each individual program is in a different member of that file
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.
