How and when to use them.
Brief: Logical files can include data from more than one underlying physical file format. Those logical files are defined as multiple-format logicals or join logicals. Although it is not particularly difficult to define either type, it is sometimes not easy deciding which type to use. This article looks at the definition and use of these two types of logical files.
It is important to be aware of the alternatives to single-format logical files. I know that in my experience, I have often written and tested a program using single-format logical files, only to realize a day or two later that a multiple-format logical file or a join logical file could have been used and would have made the program much simpler.
The alternative that seems all too obvious after the fact might not be so evident in the heat of the moment, merely because most logical files are created in response to an immediate programming need. For instance, if I need a customer search program, I start by creating a logical file ordered by the customer name. I would create that as a logical file, rather than use the Open Query File (OPNQRYF) approach, since the file will be used repeatedly and should be available as needed. This logical file is created specifically for the customer search and exists in addition to the physical or logical file that is ordered by the customer number.
The customer record probably contains fields that reference data in other files. For example, a salesman identifier may be in the record, along with a customer type code. There are also other records associated with a customer. These other records can be such things as ship-to addresses, orders and accounts receivable information. An example of the customer record appears in 1 and the related database is shown in 2.
The customer record probably contains fields that reference data in other files. For example, a salesman identifier may be in the record, along with a customer type code. There are also other records associated with a customer. These other records can be such things as ship-to addresses, orders and accounts receivable information. An example of the customer record appears in Figure 1 and the related database is shown in Figure 2.
When you write programs to work with this database, you may start out with a program similar to that shown in 3. In that program, you name all of the files that you need in the F-specs, and then in the C-specs include the code needed to access the files. This is a typical usage of the database. For each customer master record that is processed, records from the other files are retrieved, based upon the values in the customer master. Note that a great deal of code is needed just to set up the "read loop" that gets all of the associated records. As more files are added, the amount of "read code" also increases.
When you write programs to work with this database, you may start out with a program similar to that shown in Figure 3. In that program, you name all of the files that you need in the F-specs, and then in the C-specs include the code needed to access the files. This is a typical usage of the database. For each customer master record that is processed, records from the other files are retrieved, based upon the values in the customer master. Note that a great deal of code is needed just to set up the "read loop" that gets all of the associated records. As more files are added, the amount of "read code" also increases.
There is nothing wrong with this approach, but you should consider that you can get the system to do the "read loop" processing for you, simply by defining a logical file that refers to all the associated records. The example illustrates, case in point, that recognizing the alternatives to single-format logical files can save you time and effort.
Two Different Needs
If you look at the customer record format, the database files and the code sample, you will see that there are two different requirements for accessing records associated with a customer. One requirement is to access a single other record, such as the salesperson for the customer or the customer type description. The access in the RPG code is by means of the CHAIN operation. In this case, there is a "one-to-one" correspondence be-tween the customer record and the salesperson and customer type files. The other requirement is to read one-to-many associated records. For example, many address records or orders may be associated with each customer. The RPG code for this type of access is SETLL and a READE loop.
You can simplify the program code by defining either a multiple-format logical file or a join logical file. Either of those types of logical files allows you to work with data from more than one physical file. OS/400 is in charge of returning the records to your program in the correct sequence, relieving you of the coding chore. The question is, which type of logical file should you use in this situation? What pattern is there to help you decide which type to use in another case?
Multiple-format Logical Files
A multiple-format logical file is defined over two or more physical files and, as its name implies, includes more than one record format within the logical file. Each record format is usually associated with a different physical file; the record formats define the data that is included from the physical files. The record formats, then, represent records that are available to your program. When your program reads from the multiple-format logical file, the records are sequenced according to key specifications that are defined for each of the record formats.
If you have worked with a S/36 or earlier machine and have converted your files to AS/400 database files, you may have encountered multiple-format files on the old machine. It is common on those machines to put related records into the same file; for example, order header, detail and discount records would all be together. The rationale for this is that there is enough "common" information for those records that it is easier to put them all together, rather than break them out into separate files. Generally, the common fields are limited to key fields, after which the records have very little in common.
File design includes finding the longest record length of the different types, then adding a few pad bytes. Terrible design problems are perpetrated with this technique when additional fields need to be added. But it is usually done this way so that the records can be read in order, either by key or as a primary file. Apart from sorting and matching record processing, there is no easy way on the S/36 to sequence records from separate files, and besides, sorting and matching are of no help if the files need to be processed by key.
Given that a great deal of the effort in converting from the S/36 to the AS/400 involves splitting out those multiple-record type files into separate physical files, former S/36 programmers may be astonished to find that OS/400 provides a facility to group the records back into the same file. It's provided because there are valid reasons for processing your files in that manner. But there are compelling reasons to use the separate physical file technique, the primary reason being that a modification to one file of a related group does not affect the other files.
4 shows an example of the DDS that defines a multiple-format logical file for the sample database. This logical file includes the CUSMASTP file (Customer Master), the CUADDRP file (Customer Addresses), the ORDERSP file (Orders) and the ORDETLP file (Order Detail). Note that the first two record formats, CUMAST and CUADDR, are defined just as if they were in single-format logical files by themselves. However, the ORDERS and ORDETL formats include a peculiar key specification, the *NONE value.
Figure 4 shows an example of the DDS that defines a multiple-format logical file for the sample database. This logical file includes the CUSMASTP file (Customer Master), the CUADDRP file (Customer Addresses), the ORDERSP file (Orders) and the ORDETLP file (Order Detail). Note that the first two record formats, CUMAST and CUADDR, are defined just as if they were in single-format logical files by themselves. However, the ORDERS and ORDETL formats include a peculiar key specification, the *NONE value.
The primary key field for the logical file is the customer number field. This is defined in the four physical files as a decimal field, 5 digits with 0 decimal positions. To start the sequencing in the logical file, you list that key field as the first key for each of the record formats, using the name of the key field from the physical file. As in single-format logical files, you can use more than one key field. This is shown in the CUADDR format, where the second key field is the address number field. Assume for this example that the CAADNO (Address number) field is a DEC(3,0) field.
Assume also that the order number fields (ORORNO and ODORNO) in the ORDERS and ORDETL formats are defined as DEC(5,0), and that you want to use that field to sequence the order and order detail records in the logical file. This is a problem in the multiple-format logical file, since the second key field position is already defined as a DEC(3,0) field as a result of CUADDR specifying that field length prior to the ORDERS format. One of the rules for a logical file access path is that key fields in corresponding positions must be of the same data type and length. Because the second key fields for the CU- ADDR, ORDERS and ORDETL formats are different lengths [DEC(3,0) and DEC(5,0)], you cannot simply define the second key field for the order record formats as the order number field. If you try to create the logical file with unlike corresponding key fields, you'll encounter error message CPF3238 (Key field &1 not same as previous formats) and the file will not be created.
The *NONE value for the key specification is used in this situation. *NONE indicates that you do not have a field in that key field position, but that you do have key fields following. OS/400 accepts that and creates the file. When records are read from the logical file, all of the records for a customer are read from the CUADDR format before any records are read for the same customer from ORDERS. That happens because there is no relationship between the address records and the order records, other than the customer number.
The *NONE value is also used for the ORDETL format. In this case, there is a "header-detail" relationship between the ORDERS records and ORDETL records. There may be more than one detail record for each order, so those are sequenced by the order detail line number field (ODLNNO). In the ORDETL format, you see that the key fields are in agreement with the previously defined ORDERS format, so you can simply add the ODLNNO field as the last key field.
One of the strengths of logical files is their ability to use select/omit specifications for any of the record formats included in the logical file. Select/omit specifications could cause a problem, though, when utilized in conjunction with records that are used in a "header-detail" relationship. The problem occurs if the select/omit condition omits a header record but does not omit the corresponding detail records. In that case, sequentially reading the file will return detail records to your program for which a header record was not read.
Using a Multiple-format Logical File in RPG
Having done the extra work of creating a multiple-format logical file, you can take advantage of it to simplify your programs. 5 shows an RPG program fragment that reads the file. Note that the multiple read loops shown in 3 are replaced by a single read loop. The program is reading the logical file and using record identifying indicators to indicate which of the four record formats in the logical file is read.
Having done the extra work of creating a multiple-format logical file, you can take advantage of it to simplify your programs. Figure 5 shows an RPG program fragment that reads the file. Note that the multiple read loops shown in Figure 3 are replaced by a single read loop. The program is reading the logical file and using record identifying indicators to indicate which of the four record formats in the logical file is read.
The F-spec is used to specify the name of the multiple-format logical file. On the compiled listing, the record formats found in the file are listed under the file name. That is similar to the listing of a display file with multiple formats, which is the type of multiple-format file that you are probably most familiar with.
As shown in 5, we need I- specs to determine which record has been read. There is an I-spec for each of the record formats in the file. Note that the record format name is supplied on the I-spec, not the file name. Each record format is associated with its own record identifying indicator. The indicator is set on when a record is read from the file for the corresponding record format. It is vitally important that you remember that the record identifying indicators are not set off automatically if the file is read as a full procedural file. You must provide the coding to set the indicators off. If you read the file as a primary or secondary file, you do not have to set the record identifying indicators off.
As shown in Figure 5, we need I- specs to determine which record has been read. There is an I-spec for each of the record formats in the file. Note that the record format name is supplied on the I-spec, not the file name. Each record format is associated with its own record identifying indicator. The indicator is set on when a record is read from the file for the corresponding record format. It is vitally important that you remember that the record identifying indicators are not set off automatically if the file is read as a full procedural file. You must provide the coding to set the indicators off. If you read the file as a primary or secondary file, you do not have to set the record identifying indicators off.
6 shows an alternative, indicatorless method which uses the INFDS for the multiple-format logical. Simply define the INFDS, using a subfield with *RECORD in columns 44-50 of the I-specs and a field name in columns 53-58, such as RCDNAM. When you read CUSTFILL, RCDNAM will automatically contain the name of the record format just read-CUMAST, CUADDR, ORDERS or ORDETL. The field you specify for *RECORD is automatically defined as an eight-byte alphanumeric field.
Figure 6 shows an alternative, indicatorless method which uses the INFDS for the multiple-format logical. Simply define the INFDS, using a subfield with *RECORD in columns 44-50 of the I-specs and a field name in columns 53-58, such as RCDNAM. When you read CUSTFILL, RCDNAM will automatically contain the name of the record format just read-CUMAST, CUADDR, ORDERS or ORDETL. The field you specify for *RECORD is automatically defined as an eight-byte alphanumeric field.
The C-specs show a read loop that processes all records for a specific customer number. The SETLL (Set Lower Limit) operation is used to set a lower limit for a customer number against the file. You could supply a record format name as the factor 2 for the SETLL rather than the file name. For example, if you use the SETLL for record format ORDERS, then the records would be supplied from the logical file starting with the ORDERS format. When you want to read all of the records for a particular common key value, use the file name in the SETLL operation, as I've done in both examples.
After ensuring that there is at least one record in the access path with the specified customer number (indicator 98 is on), the loop starts. The record identifying indicators are set off, then a READE (Read Equal) operation is performed, again for the file. This is another operation where you can specify either the file name or the record format name. Because the program is supposed to process all records for the common key "customer," and because the program cannot predict what type of record will be supplied next, the file name is used rather than a record format name. Assuming that a record with an equal customer number key is read (indicator 99 is not set on), the program is told what type of record was read by the record identifying indicator or the RCDNAM field. For each READE operation, only one of the four record identifying indicators will be set on. The CASEQ (Case Equal) construct is shown as a simple example of how the program can process the record, once it has determined what type of record was read.
The advantage of using this method, rather than defining and reading the four files separately, is that you only need one read construct in the program, rather than four. The construct is easier to understand and maintain, since there is only one level to it. In contrast, reading the logical files used in this example as single-format logical files implies a multilevel read construct. The outer layer is a read operation against the customer master file. If that record is found, then a read loop is required to read the corresponding address file records. After that, another read loop is used to process the orders records. Embedded within that loop is a loop to read corresponding order detail records. This approach is troublesome if another file is added to the process or if a file has to be removed. For example, if order detail comment records are added, another embedded loop would have to be added to the order processing loop. With the multiple-format logical file method, you need only add another record identification I-spec and another CASEQ operation to direct processing for the comment records to their own subroutine.
If you need to process all of the records in the file, you should consider reading the file as a primary file. The processing in that case is considerably simpler, since the only required constructs are the I-spec record identifications and the CASEQ (or equivalent) constructs. The RPG cycle performs the same function as the read loop shown in Figures 5 and 6.
Ignoring a Record Format
There may be times when you need some, but not all, of the records in a multiple-format logical file. For example, using the logical file in 4, you may want to read the CUMAST, ORDERS and ORDETL records, but not the CUADDR records. You can choose either to not process the records in your program or to ignore the record format entirely.
There may be times when you need some, but not all, of the records in a multiple-format logical file. For example, using the logical file in Figure 4, you may want to read the CUMAST, ORDERS and ORDETL records, but not the CUADDR records. You can choose either to not process the records in your program or to ignore the record format entirely.
Not processing is a decision made in your program. Using the program in 5 as an example, you can ignore the CUADDR records by simply removing the CASEQ operation for *IN02. You will still need the I-spec record identification for the CUADDR format. You can include or omit the record identifying indicator on the I-spec. If you remove the I-spec, an undefined record type error will occur when the program reads from the file and gets a record from the CUADDR format, but this will not halt processing.
Not processing is a decision made in your program. Using the program in Figure 5 as an example, you can ignore the CUADDR records by simply removing the CASEQ operation for *IN02. You will still need the I-spec record identification for the CUADDR format. You can include or omit the record identifying indicator on the I-spec. If you remove the I-spec, an undefined record type error will occur when the program reads from the file and gets a record from the CUADDR format, but this will not halt processing.
The other option is to ignore the record format entirely. This is done with the F-spec continuation shown in 7. The IGNORE continuation option is used, with the name of the record format that is to be ignored. As read requests are passed to the OS/400 database, the database is informed that any records belonging in the CUADDR format are not to be given to the program. Using the IGNORE option is almost the same as removing the record format from the logical file. As far as the program is concerned, the ignored format is not in the logical file. However, the ignored records are still read by the lower level file access routines that your program uses, so there is the same overhead of the actual read from disk. Records are read and discarded until the next record for one of the included record formats is read.
The other option is to ignore the record format entirely. This is done with the F-spec continuation shown in Figure 7. The IGNORE continuation option is used, with the name of the record format that is to be ignored. As read requests are passed to the OS/400 database, the database is informed that any records belonging in the CUADDR format are not to be given to the program. Using the IGNORE option is almost the same as removing the record format from the logical file. As far as the program is concerned, the ignored format is not in the logical file. However, the ignored records are still read by the lower level file access routines that your program uses, so there is the same overhead of the actual read from disk. Records are read and discarded until the next record for one of the included record formats is read.
Using a Single-format Logical Instead of a Multiple-format Logical
You probably would not want to read a logical file such as the one used in this example to process just the CUMAST records. The reason for that is because each customer record is probably separated by a great number of other records (address records and order records). For example, two customer records could be separated by dozens or hundreds of intervening records. Reading the customer records sequentially would mean reading all of those other records also.
In this case, it would be preferable to simply have a single-format logical file defined over the customer master file. You might choose to define a single-format file even if the key is the same as the usage of the customer master in the multiple-format logical file. If you can define the access paths so that they are similar enough, the system will share the access paths between the files. That means that the apparent overhead of maintaining two logical files is not really there. A change to the access path of the single- format logical file is the same change for that record format in the multiple- format logical file. The AS/400 Database Guide gives details about how access paths can be shared.
Join Logical Files
A join logical file is used when you need to get related fields from different files into one record format. This differs from a multiple-format logical file in that there is only one record format in a join logical file, and all of the information from the related files is presented to your program in that record format. Reading one record from a join file might actually cause up to 32 physical file records to be read. A join logical file is similar to using the OPNQRYF command to create a view, although the OPNQRYF method includes the important capability of using fields from any of the joined files to form the access path. The access path of a join logical file can only be created with fields from the primary file in the join specification. (For a more complete discussion of creating join logical files, see the February 1992 issue of Midrange Computing, "Get Relation-al and Join.")
Because of the key field limitation, a join logical file cannot always be used in the place of a multiple-format logical file (or multiple-format processing in your program). For example, if the multiple-format logical file shown in 4 is instead defined as a join logical file, the entire key for the record format would be limited to fields in the CUMASTP file. That means that some of the important access path definition features are not available to you. So when special access path definitions are needed, or sequential or indexed sequential processing is required, a join logical file is probably not the best choice.
Because of the key field limitation, a join logical file cannot always be used in the place of a multiple-format logical file (or multiple-format processing in your program). For example, if the multiple-format logical file shown in Figure 4 is instead defined as a join logical file, the entire key for the record format would be limited to fields in the CUMASTP file. That means that some of the important access path definition features are not available to you. So when special access path definitions are needed, or sequential or indexed sequential processing is required, a join logical file is probably not the best choice.
Join logical files are most useful when there are related "facts" about a record in a single record of another file, not when there are multiple related "records", as in a header-detail situation. An example of related facts is shown in the sample database in 2. The customer record contains two fields, CUSLS (Salesperson) and CUTYPE (Cus-tomer Type). These fields are codes; that is, the code is kept in another database file along with descriptive information about the code. The RPG program in 3 shows how the related fact is usually retrieved: with the CHAIN operation.
Join logical files are most useful when there are related "facts" about a record in a single record of another file, not when there are multiple related "records", as in a header-detail situation. An example of related facts is shown in the sample database in Figure 2. The customer record contains two fields, CUSLS (Salesperson) and CUTYPE (Cus-tomer Type). These fields are codes; that is, the code is kept in another database file along with descriptive information about the code. The RPG program in Figure 3 shows how the related fact is usually retrieved: with the CHAIN operation.
When you are creating or updating a record that includes related fact fields, you will probably use coding such as is shown in 3. But when you read the record, either for display or printing, you can take advantage of the join logical file. Rather than recreate the code to get the related information, you define the join logical file and let the system retrieve the information. The retrieval is done as part of your read request. The record that is presented to your program includes whatever fields you defined for the customer master record, in addition to fields from related files.
When you are creating or updating a record that includes related fact fields, you will probably use coding such as is shown in Figure 3. But when you read the record, either for display or printing, you can take advantage of the join logical file. Rather than recreate the code to get the related information, you define the join logical file and let the system retrieve the information. The retrieval is done as part of your read request. The record that is presented to your program includes whatever fields you defined for the customer master record, in addition to fields from related files.
8 shows an example of a join logical file used to get fields related to the customer master record. The join is done by corresponding fields in the files. When a record is returned to the program in the CUMAST record format, the four "CU" fields are from the customer master record. In addition, the salesman name and customer type description are part of the record.
Figure 8 shows an example of a join logical file used to get fields related to the customer master record. The join is done by corresponding fields in the files. When a record is returned to the program in the CUMAST record format, the four "CU" fields are from the customer master record. In addition, the salesman name and customer type description are part of the record.
It is possible to define and use a join logical file to process records in a "header-detail" relationship. But is that really the approach that you want to use? To replace the multiple-format logical file shown in 4, you would have to create a join logical file that lists all of the fields from the four files. You would then have to create the join specifications, which in this case are more complicated because there are multiple levels of join (CUMASTP to ORDERSP, ORDERSP to ORDETLP). You will probably also have to specify a number of Join Duplicate Sequence (JDUPSEQ) statements to simulate what the key fields for each format in the multiple-format logical file provide: retrieval in order number/order line sequence. This is not a very useful construct, especially when the simpler multiple-format logical file is available as an alternative.
It is possible to define and use a join logical file to process records in a "header-detail" relationship. But is that really the approach that you want to use? To replace the multiple-format logical file shown in Figure 4, you would have to create a join logical file that lists all of the fields from the four files. You would then have to create the join specifications, which in this case are more complicated because there are multiple levels of join (CUMASTP to ORDERSP, ORDERSP to ORDETLP). You will probably also have to specify a number of Join Duplicate Sequence (JDUPSEQ) statements to simulate what the key fields for each format in the multiple-format logical file provide: retrieval in order number/order line sequence. This is not a very useful construct, especially when the simpler multiple-format logical file is available as an alternative.
On the other hand, using the join logical file in a program is certainly simpler than using the multiple-format logical file. Because you are working with only one record format, you do not need to include record identifying specifications and a control construct to direct processing for each type of record format.
Picking the Right Logical File
No hard-and-fast rules can dictate which logical file you should use, without fail, in a given situation. The choice is yours, and it's not always easy. You can choose single format logical files, multi-format logical files or join logical files. The determinants seem to be the number of physical files referenced and the likelihood of reusing the more complicated file definition. If your multiple file uses are simple header-detail situations with only two files, it may be easier to simply read the two files. However, as the short code examples have shown, the complication of the code required to read header-detail files escalates rapidly as more files are added to the relationship. This set of circumstances suggests the use of multiple-format logicals.
Deciding to use a join logical file is more complicated, primarily because a join file is read only. If your program needs to access a record for update, and there are related records, it is probably easier to just use the single- format logical files. But if there is not an update requirement, the decision is more complicated. Would you create a join logical file for only one related file? For two? This then becomes a question of frequency of use, in terms of how often you have to program for those particular files If you have a master record with many related records, it may be advantageous to create a join logical file that contains all (or as many as possible) of the related records. You can use that join logical file in any programs that use one or more of the related records, with the attitude that the additional fields that are returned are of no importance if you don't need them.
These decisions are not always easy to make. The problem is that one way, you can just use single-format logical files and write a lot of code. The other way, you can have the system do the retrieval work and write less code, but you may lose some flexibility. This is not so much of a concern with multiple- format logical files, but does apply to the read-only nature of a join logical file. Though you may still end up favoring single-format logicals in some cases, adding multiple-format and join logicals to your repertoire helps you to evaluate the best approach to each situation before you've finished the job.
References AS/400 Database Guide (SC41-9659, CD-ROM QBKA7201) Midrange Computing, February 1992, "Get Relational and Join" RPG/400 Reference (SC09-1349, CD-ROM QBKA4E01)
Multi-format and Join Logicals
Figure 1 Customer record, file CUMASTP
Figure 1: Customer Record-File CUMASTP
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
A R CUMAST TEXT('Customer master file')
A CUSNO 5 0 TEXT('Customer number')
A CUNAME 30 TEXT('Customer name')
A CUSLS 5 TEXT('Sales person ID')
A CUTYPE 5 TEXT('Customer type code')
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
Multi-format and Join Logicals
Figure 2 Sample database for customers
Figure 2: Sample Database for Customers
File Record Format Description
CUMASTP CUMAST Customer master
CUMASTL CUMAST Customer master - logical by CUSNO
CUADDRP CUADDR Customer addresses
ORDERSP ORDERS Orders master
ORDETLP ORDETL Order details
CUTYPEP CUTYPE Customer type code
SLSMSTP SLSMST Sales person master
Multi-format and Join Logicals
Figure 3 Sample RPG program to access customer database
Figure 3: Sample RPG Program to Access Customer Database
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
FCUMASTL IF E K DISK
FCUADDRP IF E K DISK
FSLSMSTP IF E K DISK
FORDERSP IF E K DISK
FORDETLP IF E K DISK
C READ CUMASTL 99*99 - EOF
C*
C* GET CUSTOMER ADDRESS RECORDS
C*
C *IN99 IFEQ *OFF *NOT EOF
C CUSNO SETLLCUADDRP 99*99 - FOUND
C*
C *IN99 IFEQ *ON *FOUND RECORD
C *IN99 DOUEQ*OFF *UNTIL NE KEY
C CUSNO READECUADDRP 99*99 - NE KEY
C .
C .
C ENDDO
C ENDIF
C ENDIF
C*
C* GET SALES PERSON RECORD
C*
C CUSLS CHAINSLSMSTP 99 *99 - NRF
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
Multi-format and Join Logicals
Figure 4 DDS for multiple-format logical file
Figure 4: DDS for Multiple-format Logical File
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
A* LOGICAL FILE CUSFILL
A* MULTIPLE-FORMAT LOGICAL OVER CUMASTP, CUADDRP, ORDERSP, ORDETLP
A
A R CUMAST PFILE(CUMASTP)
A K CUSNO
A
A R CUADDR PFILE(CUADDRP)
A K CACSNO
A K CAADNO
A
A R ORDERS PFILE(ORDERSP)
A K ORCSNO
A K *NONE
A K ORORNO
A
A R ORDETL PFILE(ORDETLP)
A K ODCSNO
A K *NONE
A K ODORNO
A K ODLNNO
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
Multi-format and Join Logicals
Figure 5 Using multiple-format logical file
Figure 5: Using Multiple-format Logical File
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
FCUSFILL IF E K DISK
ICUMAST 01
ICUADDR 02
IORDERS 03
IORDETL 04
C*
C CSNO SETLLCUSFILL 98*98 - FOUND
C*
C *IN98 IFEQ *ON *EQ KEY FOUND
C *IN99 DOUEQ*ON *UNTIL NE KEY
C SETOF 010203
C SETOF 04
C CSNO READECUSFILL 99*99 ON - NE KEY
C*
C *IN99 IFEQ *OFF *EQ KEY FOUND
C *IN01 CASEQ*ON #CUMS *CUMAST RECORD
C *IN02 CASEQ*ON #CUAD *CUADDR RECORD
C *IN03 CASEQ*ON #ORDR *ORDERS RECORD
C *IN04 CASEQ*ON #ORDT *ORDETL RECORD
C ENDCS
C ENDIF
C ENDDO
C ENDIF
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
Multi-format and Join Logicals
Figure 6 Inicatorless alternative to Figure 5
Figure 6: Indicatorless Alternative to Figure 5
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
FCUSFILL IF E K DISK
F KINFDS INFDS
IINFDS DS
I *RECORD RCDNAM
C*
C CSNO SETLLCUSFILL 98*98 - FOUND
C*
C *IN98 IFEQ *ON *EQ KEY FOUND
C *IN99 DOUEQ*ON *UNTIL NE KEY
C CSNO READECUSFILL 99*99 ON - NE KEY
C*
C *IN99 IFEQ *OFF *EQ KEY FOUND
C RCDNAM CASEQ'CUMAST' #CUMS *CUMAST RECORD
C RCDNAM CASEQ'CUADDR' #CUAD *CUADDR RECORD
C RCDNAM CASEQ'ORDERS' #ORDR *ORDERS RECORD
C RCDNAM CASEQ'ORDETL' #ORDT *ORDETL RECORD
C ENDCS
C ENDIF
C ENDDO
C ENDIF
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
Multi-format and Join Logicals
Figure 7 Ignoring a record format in multiple-format LF
Figure 7: Ignoring a Record Format in a Multiple-format Logical File
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
FCUSFILL IF E K DISK
F KIGNORECUADDR
Multi-format and Join Logicals
Figure 8 Join logical file for customer database
Figure 8: Join Logical File for Customer Database
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
A* JOIN LOGICAL FILE FOR CUSTOMER DATABASE
A*
A R CUMAST JFILE(CUMASTP SLSMSTP CUTYPEP)
A J JOIN(CUMASTP SLSMSTP)
A JFLD(CUSLS SMSLS)
A J JOIN(CUMASTP CUTYPEP)
A JFLD(CUTYPE CTTYPE)
A CUSNO
A CUNAME
A CUSLS
A SMNAME
A CUTYPE
A CTDESC
A K CUNAME
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online