Techniques for working your way out of the System/36 Environment
by Ernie Malaga
The Field Reference File
The AS/400 has been advertised as a database machine. One of the advantages of a database machine is that the system knows the attributes of every single piece of information that has been stored in its files, and that this information can be retrieved easily and efficiently. To accomplish this, the AS/400 (and its predecessor, the System/38) uses Data Description Specifications (DDS) to describe database files.
The DDS consists of a series of A-specifications describing the entire file, each record type, and the different fields contained in the record. DDS provides for all of the attributes that can be applied to a data field, such as type (character, packed numeric, and so on), length, precision, free text, column headings, alternate name, validation checking, error messages, editing, and, if a device file is being described, display or printer attributes.
There are many advantages to describing files externally from your programs through the DDS. The one that is most often cited is that you no longer must describe all the fields of your files in each program that uses the file. But there are other advantages. If you describe your files externally, you can include in the field definition settings such as edit codes, column headings, text, validity checking, and error messages. These settings are retrieved by the program compiler when the program is created. Besides, if you use Query or SQL, your printouts will be automatically edited if you included edit codes or words in your DDS.
As you work your way out of the S/36E, you should change your files from program-described to externally-described. Although you can run in native with program-described files, it is not a good idea to do so, for you will not be able to take advantage of the AS/400 database capabilities.
Before you jump into the task of externally describing your files, it is wise to choose the best approach. Let's take a moment to see how it can be done. There are two different ways:
1. Writing self-contained DDS for each file, where each field is described independently in complete detail. Most newcomers to the AS/400 choose this approach because it is as close as they can get to program-described files while still using external file definitions. It is a good compromise, but not a very efficient one.
2. Describing a Field Reference File (FRF) first, then referencing its fields in the DDS of each database file. This method is better, for reasons that will become apparent below.
What is the FRF?
As mentioned above, FRF stands for Field Reference File. Typically, an FRF is a list of fully-described data elements. The FRF should contain all the fields from all your database files that are conceptually and functionally different from one another.
The FRF has no members and therefore no records. It is used solely for the purpose of describing all data to the computer in a single location, much like a Data Dictionary would do. The FRF can then be referenced in the DDS of all individual files in order to simplify and standardize field definitions throughout the system.
Advantages of the FRF
Before we begin listing the advantages of the FRF approach, let's state for the record that there are no disadvantages. Not one. This is another way of saying that you have nothing to lose, but everything to gain, by implementing an FRF. Now that I have that out of my system, I can proceed to tell you what you will gain.
1. The description of all unique fields in your entire system will be contained in only one object. For example, if you define a customer account number field in your FRF, each file that uses customer account numbers can reference the FRF customer account number. If you need to expand the account number field from six to eight digits, you simply change one DDS line in your whole system, followed by a recompile of the FRF and each file that uses the field. This applies to any file that has been defined with DDS, be it database, display, printer, or any other type. In contrast, if you had defined the customer account number field in each separate file, you would have to change the DDS of each file, then recompile each file.
2. Coding the DDS of new files becomes a much simpler task. Suppose that you define a quantity field in your FRF, including such niceties as edit code and column headings. To include this field in a file, all you must do is reference it; the new file will incorporate the edit code and column headings automatically. If you did not use an FRF, you would have to repeat the edit code and column headings in the DDS of each file you are describing.
3. You may have different FRFs for different purposes. For example, you might have a separate FRF for display files used in interactive programs. This new FRF could reference the "basic" FRF and add not only edit codes but other DDS keywords for validity checking, error messages, and so on. This way you would not have to repeat all that code each time you write the DDS for the display file. And your users will thank you for it, since they will see the same error messages, the same display attributes, the same validity checking, no matter what program they are running. Consistency is always welcome.
Defining an FRF
There are probably as many ways to define an FRF as there are programmers, and there is no "better" or "best" way to do it. It all depends on your requirements, in the way your company does business, and in how much work you are willing to put into it. However, there are certain steps you can follow no matter how you define your FRF. Rather than giving you a general-purpose definition for each step, I will illustrate the process with a simple example.
Your Customer Master and your Vendor Master files have similar fields in their records. After looking at your requirements, it becomes obvious that you need to store the following data for each customer or vendor:
- Identification Number - Name - Two lines of address - City - State - Zip Code - Telephone - Contact Name - A fifty-character remark
1 shows how we can begin building our FRF.
Figure 1 shows how we can begin building our FRF.
This is not all there is to be of the FRF. You will notice that we have defined only those fields which are unique in attributes and purpose.
We have also defined separate fields for the name and the address, since they serve different purposes. But we have not defined two separate fields for the two lines of address, since these are functionally the same.
Finally, notice that all fields have column headings (COLHDG), and that numeric fields are being edited (EDTCDE or EDTWRD keywords). This way you will not have to repeat this editing in each display or printer file you create.
The second step in the creation of our FRF is to add to the FRF the actual fields that will be used by programs. This can be seen in 2.
The second step in the creation of our FRF is to add to the FRF the actual fields that will be used by programs. This can be seen in Figure 2.
The top portion works as an area of all generic field definitions. Following that there is a section for each file, in which we define each unique field in our system by simply referencing the top portion field that best suits us, or by creating a brand-new field. For example, the Customer Master file requires two lines of address. Since we have defined a generic ADDRESS field, we can simply reference it in the Customer Master section of the FRF.
This referencing is done by coding an "R" in column 29 of the A-spec, and including the REFFLD (Reference Field) keyword to indicate which field is being referenced. Please note that since the generic fields at the top of the FRF are never used in any programs, they can have long names (up to ten characters) without our having to concern ourselves with the limitations of RPG. The field names used in each database file section, however, should be kept to a maximum of six characters if RPG is to be the main programming language.
How Do I Use The FRF?
Once you have taken the trouble of defining an FRF, you can begin using it next time you write the DDS for a file of any kind (database, printer, display, and so on). For example, Figures 3a and 3b show what the Customer Master file and a display file might look like. This display file is used to inquire into the Customer Master database file.
At the top of the DDS we find the REF keyword. This keyword indicates the name of the file that will be used as a reference, that is, the file containing the fields referenced by the REFFLD keyword. It is important to realize that we are referencing not the "common" portion of the FRF but the portions that define the fields in each file - the Customer Master file in this case. Also, since the FRF already contains edit words and edit codes, we do not have to code them all over again in this display file.
Making Changes
Among the myriad of Murphy's Laws, there must be one saying that no matter how much you prepare for change, changes will catch you unaware and will cause grief. For example, the Postal Service may decide next year that the zip code ought to have ten digits instead of nine.
If your files had been defined without the help of an FRF, you would then have to change the DDS of each file containing zip codes and recompile them. When an FRF is used, on the other hand, we only change one line of our FRF, then recompile the FRF and the files. Of course you still must recompile the programs that use these files, one way or the other. Where the FRF helps you is in not having to change the source DDS of each file.
Organization and Order
Once you set up your FRF and begin using it, you will begin noticing the benefits of better organization in your database. Field Reference Files are just one way to take advantage of the database, however. Other methods will be discussed in upcoming Going Native articles.
Going Native: The Field Reference File
Figure 1 Beginning of our FRF
Figure 1: Beginning of Our FRF ....1.... ....2.... ....3.... ....4.... ....5.... ....6.... ....7.... A R FRFREC A ACCT6 6 0 COLHDG('Account' 'Number') A EDTCDE(3) A NAME30 30 COLHDG('Name') A ADDRESS 30 COLHDG('Address') A CITY_NAME 20 COLHDG('City') A STATE_CODE 2 COLHDG('State') A ZIP_CODE 9 0 COLHDG('Zip' 'Code') A EDTWRD(' - ') A PHONE_US 10 0 COLHDG('Phone' 'Number') A EDTWRD(' / - ') A TEXT50 50 COLHDG('Text') ....1.... ....2.... ....3.... ....4.... ....5.... ....6.... ....7....
Going Native: The Field Reference File
Figure 2 Complete FRF
Figure 2: Complete FRF ....1.... ....2.... ....3.... ....4.... ....5.... ....6.... ....7.... A R FRFREC A ACCT6 6 0 COLHDG('Account' 'Number') A EDTCDE(3) A NAME30 30 COLHDG('Name') A ADDRESS 30 COLHDG('Address') A CITY_NAME 20 COLHDG('City') A STATE_CODE 2 COLHDG('State') A ZIP_CODE 9 0 COLHDG('Zip' 'Code') A EDTWRD(' - ') A PHONE_US 10 0 COLHDG('Phone' 'Number') A EDTWRD(' / - ') A TEXT50 50 COLHDG('Text') A* A* Customer Master File A CUCUST R REFFLD(ACCT6) A COLHDG('Customer' 'Number') A CUNAME R REFFLD(NAME30) A COLHDG('Customer' 'Name') A CUADR1 R REFFLD(ADDRESS) A COLHDG('Customer' 'Address 1') A CUADR2 R REFFLD(ADDRESS) A COLHDG('Customer' 'Address 2') A CUCITY R REFFLD(CITY_NAME) A COLHDG('Customer' 'City') A CUSTTE R REFFLD(STATE_CODE) A COLHDG('Customer' 'State') A CUZIPC R REFFLD(ZIP_CODE) A COLHDG('Customer' 'Zip') A CUPHNE R REFFLD(PHONE_US) A COLHDG('Customer' 'Phone') A CUATTN R REFFLD(NAME30) A COLHDG('Customer' 'Attention') A CURMKS R REFFLD(TEXT50) A COLHDG('Customer' 'Remarks') A* A* Vendor Master File A VEVEND R REFFLD(ACCT6) A COLHDG('Vendor' 'Number') A VENAME R REFFLD(NAME30) A COLHDG('Vendor' 'Name') A VEADR1 R REFFLD(ADDRESS) A COLHDG('Vendor' 'Address 1') A VEADR2 R REFFLD(ADDRESS) A COLHDG('Vendor' 'Address 2') A VECITY R REFFLD(CITY_NAME) A COLHDG('Vendor' 'City') A VESTTE R REFFLD(STATE_CODE) A COLHDG('Vendor' 'State') A VEZIPC R REFFLD(ZIP_CODE) A COLHDG('Vendor' 'Zip') A VEPHNE R REFFLD(PHONE_US) A COLHDG('Vendor' 'Phone') A VEATTN R REFFLD(NAME30) A COLHDG('Vendor' 'Attention') A VERMKS R REFFLD(TEXT50) A COLHDG('Vendor' 'Remarks') ....1.... ....2.... ....3.... ....4.... ....5.... ....6.... ....7....
Going Native: The Field Reference File
Figure 3A Customer master file referencing FRF
Figure 3a: Customer Master File, Referencing FRF ....1.... ....2.... ....3.... ....4.... ....5.... ....6.... ....7.... A REF(FRF) A R CUREC A CUCUST R A CUNAME R A CUADR1 R A CUADR2 R A CUCITY R A CUSTTE R A CUZIPC R A CUPHNE R A CUATTN R A CURMKS R ....1.... ....2.... ....3.... ....4.... ....5.... ....6.... ....7....
Going Native: The Field Reference File
Figure 3B Display file referencing FRF
Figure 3b: Display File, Referencing FRF ....1.... ....2.... ....3.... ....4.... ....5.... ....6.... ....7.... A DSPSIZ(24 80 *DS3) A REF(FRF) A PRINT A INDARA A CF03(03 'Exit') A CF12(12 'Cancel') A R DETAIL A BLINK A 1 25'Display Customer Information' A 4 2'Customer number:' A @CUST R B 4 25REFFLD(CUCUST) A 6 2'Full name and address:' A @NAME R O 6 25REFFLD(CUNAME) A @ADDR1 R O 7 25REFFLD(CUADR1) A @ADDR2 R O 8 25REFFLD(CUADR2) A @CITY R O 9 25REFFLD(CUCITY) A @STATE R O 10 25REFFLD(CUSTTE) A @ZIP R 0O 10 29REFFLD(CUZIPC) A 12 2'Contact:' A @ATTN R O 12 25REFFLD(CUATTN) A 14 2'Phone number:' A @PHONE R 0O 14 25REFFLD(CUPHNE) A 16 2'Remarks:' A @RMKS R O 16 25REFFLD(CURMKS) A 23 2'F3=Exit F12=Cancel' ....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