Read without ads and support Scribd by becoming a Scribd Premium Reader.

Language:

Download

Go BackAdd Note

Link

Embed

Save for later

Joining Files Programming- General Written by Ted HoltSaturday, 30 June 1990 18:00Access information from more than one file at a time with this modern database technique by Ted HoltIf you moved into the System/38-AS/400 world after working with the System/34-36, as I did,you may feel overwhelmed at the difference in the two environments. Many of the differences aresimply extensions of what you already know, such as using data areas. Other differences justinvolve using new techniques, such as treating RPG indicators as data fields.But the AS/400 is a database machine, built upon new concepts, so the majority of the differencesfrom your old environment proceed from a change in philosophy. If we consider the topic of thisarticle on the join file to simply be a new technique, we fail to understand not only what joining isall about, but also what the AS/400 is all about. Joining files is not a new tool to add to our coder's toolbox - it is part of the philosophy of relational database management systems.What is Joining?Joining is combining data from two or more files into one record format, based on commonfields. In other words, to the user (a program, or a human using a query tool) each record appearsto have come from one file although it really contains data from two or more files.Joining doesn't retrieve any information that the programmer couldn't get just by reading multipleinput files. It is common to read a primary file sequentially, and then use the RPG CHAINoperation or the COBOL random READ to get additional information from other files. Readingmultiple input files doesn't increase system overhead by adding another logical file for the systemto maintain. So why join?To help us understand the rationale behind joining, let's review two relational database conceptsyou've probably heard of before: normalization and view. Normalization is the process of breaking up some types of records into smaller records, withoutlosing the ability to retrieve the data that was contained in the original record. Normalization willeliminate data redundancies and maximize the flexibility and useability of the data. Withnormalization, you'll find the number of physical files increasing - one file may become two or three. It may seem like quite a mess, but nothing you can't clean up with views.The term "view" refers to the fact that a user doesn't have to see the data in exactly the way it isstored in the database. A logical file which includes only certain fields is a view. A logical filewhich includes only certain records (through select and omit criteria) is also a view. Logicalswhich concatenate fields into other fields are views. Views allow each user to see the data in theway that he wants to see it.Your users don't care if you store their data in one big file or a dozen small ones. They do care if you don't give them all the information they need. If you give them too much information, youmay lose your job. Views let your database appear differently to different people.You should join files for two reasons: one, to be able to normalize your database; and two, to present data to users (both programs and humans) in the way that they wish to see it.Types of JoinsRelational database textbooks are full of pages explaining many types of joins. For our purposes,we need to consider only three: the inner join, the partial outer join, and the exception join. Theseare distinguished by what happens when a record from the primary join file has no matching

records in the secondary files. Figures 1 and 2 contain data from two files, customer master andsales history, which we'll use in our illustrations.If you have joined files with Query/36, you're already familiar with the inner join. Inner joinscreate resultant records for records with matching values in both files. Let's join the sales historyfile to the customer master file with an inner join. The records we get are shown in 3. Notice thatorder 50013 is not in the resultant file because the customer master file has no records withcustomer number 106.If you have joined files with Query/36, you're already familiar with the inner join. Inner joinscreate resultant records for records with matching values in both files. Let's join the sales historyfile to the customer master file with an inner join. The records we get are shown in Figure 3. Notice that order 50013 is not in the resultant file because the customer master file has no recordswith customer number 106.If we want to see all history records, we'll have to use a partial outer join. Like the inner join, the partial outer join retrieves records with matching values. Unlike the inner join, the records whichhave no matching value in the secondary file will be joined to a null record, a nonexistent recordof default values.4 illustrates the same join as before, but using a partial outer join instead of an inner join. Order 50013 has been joined to a nonexistent blank customer record, which has a blank customer nameand zero sales rep number. Default values for character fields are blanks and for numeric fields,zero. To give a field a different default value, use the DFT keyword in the DDS.Figure 4 illustrates the same join as before, but using a partial outer join instead of an inner join.Order 50013 has been joined to a nonexistent blank customer record, which has a blank customer name and zero sales rep number. Default values for character fields are blanks and for numericfields, zero. To give a field a different default value, use the DFT keyword in the DDS.The e 5 shows the results of an exception join. Since order 50013 is the only one with nomatching customer number in the customer master file, it is the only order returned by the join.Another way of looking at it is thus: inner + exception = partial outer. Those that joinsuccessfully, plus those that don't, yield all records.Join Logical FilesJoin logical files are the easiest way to define joins on the S/38 and AS/400. Once you define andcompile a join logical, your programs can use it as they do any file, with a few restrictions.Before we get into the limitations of join logicals, let's study the DDS required to join the saleshistory file and the customer master file (shown in 6).Before we get into the limitations of join logicals, let's study the DDS required to join the saleshistory file and the customer master file (shown in Figure 6).The first keyword in this file, even before the record format definition, is JDFTVAL (Join DefaultValue). If this keyword is present in the DDS, the join will be a partial outer join. Otherwise, the join is an inner join.The JFILE keyword in the record format definition tells which files to join. The first file listed, inthis case the SLSHIST file, is the primary file. All other files are secondary.A join specification, coded with a J in column 17, tells how the files are to be joined. One joinspecification is required for every pair of files. (Joining three files would require two join specs;four files would require three, and so on.) The JOIN keyword, which is optional if only two filesare being joined, tells which pair of files this specification is joining. The JFLD (Join Field)keyword tells which fields to match. Here, the customer number has the same name in both files.The fields to be included in the join logical must be listed next. If an included field is found in

more than one file, you must indicate which file's value is to be used. JREF(1) (Join Reference)means that the value of CUSNBR is to be taken from the first file, SLSHIST.Defining a key field lets us read it in a sorted sequence. All key fields must be from the primaryfile.You may also include select/omit specs, but if you do, you must add the DYNSLT (DynamicSelect) keyword at the file level (before the R spec).Join logicals have a few limitations which you need to keep in mind. One, you can't do exception joins with join logicals. Two, the key fields must all come from the primary file. Three, joinlogicals can only join physical files. (Ideally, you shouldn't have to worry about whether a file isa physical or a logical.) Four, you can't update through a join logical file. Instead, you mustupdate through a physical or a non-join logical. You can get around all of these limitations byusing Open Query File (OPNQRYF), except for the last one.Joining files with OPNQRYFIf you want to get around limitations one and three, you'll have to let OPNQRYF join the files.OPNQRYF handles inner, partial outer, and exception joins with the JDFTVAL parameter, whichlooks like its DDS counterpart, but differs in that it takes a parameter value. JDFTVAL(*NO), thedefault, is for inner joins. You can get a partial outer join with JDFTVAL(*YES). If you want anexception join, specify JDFTVAL(*ONLYDFT). If any of the files being joined is itself a joinlogical, it must agree with this parameter.To overcome the second limitation, when you need to order a join logical by a field from thesecondary file, specify the key field on an OPNQRYF command. 7 illustrates how we could sortthe CUSHIST file on sales rep number, which comes from the secondary file.To overcome the second limitation, when you need to order a join logical by a field from thesecondary file, specify the key field on an OPNQRYF command. Figure 7 illustrates how wecould sort the CUSHIST file on sales rep number, which comes from the secondary file.You'll also have to work with the FILE, JFLD, FORMAT, and MAPFLD parameters when joining with OPNQRYF. List the files you are joining, primary first, in the FILE parameter. Usethe FORMAT parameter to tell OPNQRYF how the high-level language expects the data to look.Put the name of any file here, and if the file is a multi-format file, add the name of the format touse. (If no file has exactly the fields you need, create a physical file with no members in it.) Besure to code the same file in your HLL program as well. When you override the format file to the primary join file, the program will not read the actual data, but the query.The JFLD parameter, like the JFLD keyword in DDS, tells which fields to use to join the files. Itssyntax is different, in that one JFLD parameter is used in place of several JFLD keywords.If the same field name is found in more than one file, use the MAPFLD parameter to indicatefrom which file to retrieve the field value.8 illustrates these keywords. WORK is a file which has all of the fields needed for the HLL program. The actual data will come from the sales rep master file and the join logical calledCUSHIST. Since CUSHIST is a partial outer join logical, OPNQRYF must also indicate a partialouter join with JDFTVAL(*YES). The SLSREP field is used to make the join. The MAPFLDtells OPNQRYF to get the value of SLSREP from the sales rep master file. (If we told it to get thevalue of SLSREP from the CUSHIST file, it would return a zero sales rep number for sales repswith no sales.)Figure 8 illustrates these keywords. WORK is a file which has all of the fields needed for theHLL program. The actual data will come from the sales rep master file and the join logical calledCUSHIST. Since CUSHIST is a partial outer join logical, OPNQRYF must also indicate a partial