Q: Could someone please enlighten me on the best way to combine data from two files, perform record selection and resequence the file for use by RPG/400?
My situation is this: I have two externally described physical files on my system, an order header file (containing current orders) and a past sales file (containing invoiced orders). Each file has a unique record format name, but identical file layouts and field names. I need to combine all records from both files to be used by an RPG/400 program as an IP file for a monthly report. Bear in mind that the order header file has 10,000 records and the past sales file can have as many as 600,000 records.
I first tried building a multiple-format logical file that contained the two files and then used OPNQRYF for record selection and resequencing. Result: OPNQRYF bombed out due to multiple record formats in the logical file. Then I tried joining the two files using OPNQRYF and it bombed again! This error message indicated that I couldn't have the same field names in both files. From reading the manuals (a lot of manuals!), a joined-logical file using DDS is out of the question since I need every record and field from both files.
After pulling out most of my hair in clumps, I have finally reverted to this: building an empty physical file as a work file, using CPYF (twice) to combine the two files into the work file and then using a standard OPNQRYF against the work file for record selection and resequencing. The program now runs fine, but it is obviously very slow in the file build and record selection departments, as well as gobbling up much needed resources.
There must be a better way?!
A: There is! You were on the right track with your first approach, building a multiple-format logical file. The problem was that instead of defining a separate record format for each of the physical files, what needs to be done is to define one record format and specify both of the physical files on that format.
For example, if two physical files, PHYFIL01 and PHYFIL02, as shown in1a and 1b, needed to be combined into one logical file you would use the DDS shown in 1c. The names to the physical files (up to 32) are specified using the PFILE keyword. If all of the fields of one of the physical files are to be included, use that format name in the logical file. DDS will find all of the fields that the format you specify--in this case FORMAT1--has in common with the other files you specified on the PFILE keyword. It takes this information and creates a format that contains all of the fields that are common to all of the files. In other words, a field must be in each and every one of the files to be included in this format. A key field must also be specified, in this case FIELD1, since DDS requires that if more than one file is specified on the PFILE keyword, a key must be specified. If, on the other hand, you wanted to include only selected fields from the physical files, you could use the DDS shown in 1d.
For example, if two physical files, PHYFIL01 and PHYFIL02, as shown in Figures 1a and 1b, needed to be combined into one logical file you would use the DDS shown in Figure 1c. The names to the physical files (up to 32) are specified using the PFILE keyword. If all of the fields of one of the physical files are to be included, use that format name in the logical file. DDS will find all of the fields that the format you specify--in this case FORMAT1--has in common with the other files you specified on the PFILE keyword. It takes this information and creates a format that contains all of the fields that are common to all of the files. In other words, a field must be in each and every one of the files to be included in this format. A key field must also be specified, in this case FIELD1, since DDS requires that if more than one file is specified on the PFILE keyword, a key must be specified. If, on the other hand, you wanted to include only selected fields from the physical files, you could use the DDS shown in Figure 1d.
The logical file that is created can be used in the same way as any other logical file, including being processed by OPNQRYF. There is one restriction, however: the logical file can't be used to provide an external file definition for RPG/400. The reason for this is that the logical file created is actually a multiple-format logical file, but all of the formats have the same name. This doesn't seem to bother OPNQRYF, but since RPG/400 doesn't allow duplicate format names, a problem arises. Normally you would just RENAME the format in the F spec, but in this case you can't because RPG/400 wouldn't know which of the formats to rename. The easiest solution is, if you are using the format of an existing file as we did is 1c (page 63), use the name of that physical file in your RPG program and then use an OVRDBF when you run the program. Another way would be to create a temporary physical file that contains all the information that RPG/400 needs, and then after the program is compiled, delete it.
The logical file that is created can be used in the same way as any other logical file, including being processed by OPNQRYF. There is one restriction, however: the logical file can't be used to provide an external file definition for RPG/400. The reason for this is that the logical file created is actually a multiple-format logical file, but all of the formats have the same name. This doesn't seem to bother OPNQRYF, but since RPG/400 doesn't allow duplicate format names, a problem arises. Normally you would just RENAME the format in the F spec, but in this case you can't because RPG/400 wouldn't know which of the formats to rename. The easiest solution is, if you are using the format of an existing file as we did is Figure 1c (page 63), use the name of that physical file in your RPG program and then use an OVRDBF when you run the program. Another way would be to create a temporary physical file that contains all the information that RPG/400 needs, and then after the program is compiled, delete it.
TechTalk: Combining Files Through a Logical View
Figure 1A DDS for PHYFIL01
Figure 1a: DDS for PHYFIL01 A R FORMAT1 A FIELD1 5P 0 A FIELD2 25A A FIELD3 10A A K FIELD1
TechTalk: Combining Files Through a Logical View
Figure 1B DDS for PHYFIL02
Figure 1b: DDS for PHYFIL02 A R FORMAT2 A FIELD1 5P 0 A FIELD2 25A A FIELD3 10A A K FIELD1
TechTalk: Combining Files Through a Logical View
Figure 1C DDS for including all records from two PFs
Figure 1c: DDS for Including All Records From Two Physical Files A R FORMAT1 PFILE(PHYFIL01 PHYFIL02) A K FIELD1
TechTalk: Combining Files Through a Logical View
Figure 1D DDS for including only selected fields
Figure 1d: DDS for Including Only Selected Fields A R FORMAT3 PFILE(PHYFIL01 PHYFIL02) A FIELD1 A FIELD2 A K FIELD2
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