02
Sat, Nov
2 New Articles

Going Native: The Field Reference File

General
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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.... 
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: