Part 1: Subfile Foundations: (July 1992) Complete understanding of any subject begins with a starting point to build upon. Laying the foundation for subfile usage requires familiarization with underlying concepts and basic definitions. As a prelude to the specific code used to implement a subfile, this article lays out a basic understanding of what a subfile is, how one is implemented and why subfiles exist in the first place.

Part 2: Basic Subfile Coding: (August 1992) We begin examining the coding of the display file and HLL program along with the logic and structure of typical subfile programs. The article uses an example of a subfile with "Position to" capability and presents the techniques and logic changes required to code a Modified Load-All, Expanding or Page-at-a-Time subfile.

*Part 3: Increased Functionality: (Sept. 1992) In this article, you learn to hone your coding skills for effective use of subfiles. The specific subfile techniques and keywords discussed will allow you to put expanded control and capability into the subfiles introduced in the previous article. Additionally, the article examines the difference between input and output subfiles and the special logic requirements for coding them.

Part 4: Fine-Tuning Your Subfiles: (Oct. 1992) You'll learn to customize subfiles for peak performance. This article examines the coding required to write effective subfiles and present them on-screen without clearing the lines behind the subfile. It further discusses cursor control, determination of cursor position and the coding of a point-and-shoot type of interface to AS/400 programs.

These keywords will expand your horizons far beyond subfile inquiries.

In the first two articles in this series, we presented basic subfile concepts and coding techniques. Once you understand the special syntax and logic designed into the OS/400 implementation of subfiles, you can use them to greatly simplify your applications. The first rule is to recognize which applications can use subfiles effectively. Nearly any data that you might visualize in columns, such as state codes, order detail information or customer invoice data, can be coded using subfiles.

The examples we covered in the previous articles presented simple inquiry functions using minimal subfile keywords. This month, we expand the techniques you've learned so far and present some additional keywords. At the conclusion of the article, we pull everything together and create an input-capable subfile application. This technique is a classic fit for order entry, where there are a variable number of detail lines on the order, or for full table maintenance where all the table entries can be maintained at one time. It has distinct performance advantages over single-line data entry programs, especially for remote sites. An entire batch of entries can be processed with one read or write to the remote location.

The subfile techniques covered in this article can be used for many different types of applications. The input-capable subfile merely provides a convenient vehicle to show them in action. The true complexity in coding input-capable subfiles is not the subfile techniques themselves, but the logic required to update the database file. Before tackling the more complicated task, let's warm up with an examination of subfile techniques.

Using the Subfile to Store Data-Hidden Fields

In general, codes, numbers and transaction types are not necessary to navigate an AS/400 application. Users should be able to locate what they are after on the screen via some sort of a search list and then specify the action they wish to perform. This is the object-action principle stressed in the Common User Access (CUA) portion of SAA. There is no point in burdening the user with having to see the customer number on the screen all the time if customer numbers are not really essential to navigate the application in the first place.

One very useful technique is to tack information that will be useful later in the program onto the subfile record without showing it on the screen. This is accomplished by adding fields to the record format with a usage type of "H" for hidden. The subfile DDS in 1 is very typical of the AS/400. Notice the "H" in position 38 for the CSNUM field.

One very useful technique is to tack information that will be useful later in the program onto the subfile record without showing it on the screen. This is accomplished by adding fields to the record format with a usage type of "H" for hidden. The subfile DDS in Figure 1 is very typical of the AS/400. Notice the "H" in position 38 for the CSNUM field.

For illustrative purposes, let's assume that we want to display a list of customer names, cities, states and phone numbers in a subfile. The user may want to select one or more of these and branch to a program that displays the customer's orders. The order header file contains a foreign key of customer number that we will need to determine this customer's orders; however, customer number is not on the screen. A foreign key is the reference key or code to a related file which is stored as data (for example, the customer number in the order header file or the department number in an employee file).

By adding the customer number to the subfile as a hidden field, the number will be loaded into the subfile record with the other customer information in the load routine. When changed records are read back from the subfile, the subfile returns the customer number with the rest of the information and it can be used to locate the customer's orders via the foreign key to the order header file.

Don't confuse hidden fields with non-display fields. Non-display fields have DSPATR(ND). Their contents don't appear on the screen, but the field itself occupies space. Hidden fields, on the other hand, are not only invisible-they don't occupy any screen space either.

Controlling the Subfile Page-SFLRCDNBR

The Subfile Record Number (SFLRCDNBR) keyword is used on the subfile control record to determine what page of the subfile will appear when the subfile is displayed. We touched upon this technique in the previous articles-here we cover all the details. 2 shows a fragment of DDS for a subfile control record-the control record handles all subfile function, while the subfile record merely stores data fields. The highlighted line contains the SFL-RCDNBR keyword.

The Subfile Record Number (SFLRCDNBR) keyword is used on the subfile control record to determine what page of the subfile will appear when the subfile is displayed. We touched upon this technique in the previous articles-here we cover all the details. Figure 2 shows a fragment of DDS for a subfile control record-the control record handles all subfile function, while the subfile record merely stores data fields. The highlighted line contains the SFL-RCDNBR keyword.

The numeric field associated with SFLRCDNBR must contain the number of an existing subfile record. This field must be a zoned decimal (S in position 35) field with zero decimal positions, and it can be up to four digits in length. When the subfile is displayed, the page which contains the record whose number is in RRN will be presented. CURSOR is optional. It indicates that the cursor is to be placed in the first input-capable field of the record identified by the record number.

If you are going to do any programming with subfiles that will hold more than one page, you will probably wind up using this keyword. It is typically used (as we did on our expanding subfile example) to control which page is initially presented when the subfile is displayed. It is also commonly used to return the user to the page that he left while performing other functions based upon record selection. For example, suppose a user scrolls through three pages, locates the record he wants and requests an inquiry. When he returns to the subfile, the same page that was displayed when he left the subfile should be redisplayed.

I often use the same field name both in the SFL-RCDNBR keyword and in the RPG program's F-spec, as shown in Figures 2 and 3. However, this is not mandatory. The RPG field must be numeric with zero decimal positions and large enough to contain the largest record number for the subfile. After dropping through the load logic, the RRN field contains the record number of the last record loaded on the screen. When the screen is written, that page will be displayed. When we read the changed records back from the subfile (via READC or CHAIN), the RRN field will contain the record number of the last selection processed. This positions the subfile to the page of the last processed selection when it is redisplayed.

Checking It Twice-SFLNXTCHG

If the user keys an invalid value into a subfile record, your program discovers the error when you process the record in your read changed loop. When a subfile is read back into a HLL program, we typically read only those records that have been selected or changed by the user. In RPG/400, the READC operation automatically selects changed records, while a COBOL program adds a NEXT MODIFIED clause to READ to accomplish the same purpose. Any errors are redisplayed for the user. However, if the user does not correct the entry, it is not flagged as changed; therefore, it is not picked up in the next read changed loop. As a result, the error goes unedited on the second press of the Enter key.

To correct this, the Subfile Next Change (SFLNXTCHG) keyword is coded on the subfile record format. This record-level keyword allows you to flag a subfile record as changed, even though the user has not touched it. An optional indicator is almost always used so you can control when to mark a subfile record as changed. (See 4.) When a record is determined to have invalid data, the processing loop is modified to set the SFLNXTCHG indicator on and update the subfile record. This marks the record as changed so that it will be edited again on the next pass.

To correct this, the Subfile Next Change (SFLNXTCHG) keyword is coded on the subfile record format. This record-level keyword allows you to flag a subfile record as changed, even though the user has not touched it. An optional indicator is almost always used so you can control when to mark a subfile record as changed. (See Figure 4.) When a record is determined to have invalid data, the processing loop is modified to set the SFLNXTCHG indicator on and update the subfile record. This marks the record as changed so that it will be edited again on the next pass.

This is probably the first time we have discussed updating subfiles. Since the subfile is completely separate from the database file and has display attributes, we can update the data (as the user does when keying in changes), or the indicators which control that individual record's attributes. Each subfile record has its own copy of the indicators.

Let's say we are writing an order entry subfile. One of the fields in the subfile is the part number being ordered. We must edit to ensure that the part number ordered matches a part on the part file. Assume that we have the SFLNXTCHG keyword placed on our subfile record with indicator 35 conditioning the keyword. We would ensure that 35 is off when we initially load the subfile. The process routine is illustrated in 5.

Let's say we are writing an order entry subfile. One of the fields in the subfile is the part number being ordered. We must edit to ensure that the part number ordered matches a part on the part file. Assume that we have the SFLNXTCHG keyword placed on our subfile record with indicator 35 conditioning the keyword. We would ensure that 35 is off when we initially load the subfile. The process routine is illustrated in Figure 5.

With this logic, we set the change flag of a subfile record which contains an invalid part so that it will be read on the following pass. This, along with additional logic for processing changes until there are no more errors, should snag the erroneous part number until it passes the edit. Although you can find other reasons to mark a record as changed for later retrieval, the most common usage occurs when there is an input-capable field in the subfile that you need to validate within your program.

Error Messages-SFLMSG and SFLMSGID

When a subfile record contains invalid information, we want to display an error message conveying the problem to the user. Generally, error messages are associated with a field. However, in a subfile, all user interaction is controlled by the control record. In our example, we will be executing the HEADER format to display a message about one of the fields of a subfile record.

The Subfile Message (SFLMSG) and Subfile Message ID (SFLMSGID) keywords allow you to associate either message text or a message ID at the record level, so that when the control record is written, the message appears at the bottom of the screen. Whether you use message IDs or text is a matter of taste. I use message IDs to externalize and centralize message text from my screens as well as to provide additional message characteristics-severity, second-level text, message logging, alerts. I also use message IDs to streamline implementation of national language support, but this is another story.

Consider the screen DDS in 6a. Two of the fields in the subfile have error conditions that are to be validated in the program. Error message IDs have been assigned to the control record with conditioning indicators 45 and 46. Indicators 35 and 36 are used in each individual subfile record to set the display attributes and change flag (SFLNXTCHG). Indicators 45 and 46 are record level and reflect the cumulative errors that occurred. During subfile processing, if even one record was flagged with 35, 45 would be set; and if even one subfile record was flagged with 36, 46 would be set.

Consider the screen DDS in Figure 6a. Two of the fields in the subfile have error conditions that are to be validated in the program. Error message IDs have been assigned to the control record with conditioning indicators 45 and 46. Indicators 35 and 36 are used in each individual subfile record to set the display attributes and change flag (SFLNXTCHG). Indicators 45 and 46 are record level and reflect the cumulative errors that occurred. During subfile processing, if even one record was flagged with 35, 45 would be set; and if even one subfile record was flagged with 36, 46 would be set.

Each subfile record has the part, quantity, description, and two indicators- 35 and 36, since these indicators are used on the record. This means that each record has its own copy of these indicators which are set on or off when the record is written or updated. This is how the system can highlight the erroneous data in every subfile record with only one set of indicators.

By setting on indicators 45 and 46 when an error is found (as illustrated in 6b), we can display the appropriate error message.

By setting on indicators 45 and 46 when an error is found (as illustrated in Figure 6b), we can display the appropriate error message.

Initializing the Subfile-SFLINZ and SFLRNA

In the examples in the previous parts of this series, we consistently used the Subfile Clear (SFLCLR) keyword to clear the contents of the subfile before we loaded information into it. For an input subfile, we don't want to clear the records, but rather initialize them so that the user will have blank records to key into. This is handled by replacing the SFLCLR with its sister keyword SFLINZ (Subfile Initialize).

Another keyword, Subfile Record Not Active (SFLRNA), can be used in conjunction with SFLINZ. It specifies that as records are initialized, they should not be made active unless either the program proceeds to load information into them or the user keys information into them. Unless a record is made active, it is not picked up by any sort of read operation.

Without SFLRNA, we would have to read the maximum number of records defined for the subfile. Then the HLL program would need to determine (e.g., by comparing a field to blanks) which records actually contain data. Since READC (and equivalents in other languages) are only in effect for a single press of the Enter key, SFLRNA can be used to streamline the process of reading back the information in the subfile when the user completes his entries and the HLL program needs to update the database. Rather than reading every record in the initialized subfile to see if it contains valid entries, we will read the records until we hit a logical end-of-file which will occur when there are no more active records. 7 contains an example of coding these two keywords.

Without SFLRNA, we would have to read the maximum number of records defined for the subfile. Then the HLL program would need to determine (e.g., by comparing a field to blanks) which records actually contain data. Since READC (and equivalents in other languages) are only in effect for a single press of the Enter key, SFLRNA can be used to streamline the process of reading back the information in the subfile when the user completes his entries and the HLL program needs to update the database. Rather than reading every record in the initialized subfile to see if it contains valid entries, we will read the records until we hit a logical end-of-file which will occur when there are no more active records. Figure 7 contains an example of coding these two keywords.

Input-capable Subfiles

Now let's try to pull several of these techniques together into an input- capable subfile-a subfile where some fields are designated as input or input/output. Since this technique can process an entire batch of entries with a single I/O, it provides a terrific means of performing maintenance on table entries or columns of order entry data.

The true complexity of input-capable subfiles is not the subfile techniques themselves, but the logic involved in posting a batch of entries over an entire file or portion of the file. This is the point where a medieval knight would see an ominous marking on the map that reads, "Beyond this point lie monsters!" While the I/O can be minimized, the program complexity builds, since we are really writing an interactive batch program.

From the standpoint of managing the subfile, we initialize rather than clear. Also, we may have a load routine (if the user is maintaining existing information), a display routine and a routine to process changes. We can write this as a load-all, expanding, or page-at-a-time subfile with little difference between the logic of output only and input subfiles.

The tricky portion of the coding deals with figuring out what we have when the user finally presses Enter and gives us back a subfile full of data. If all fields were given to the user to change, he could have made any number of alterations. For instance, he could have blanked out a record, changed the key of a record, added some new records, swapped keys on two records in the database or added two records with the same key. Users are very creative! Once we've determined that what we have left is valid, we need to figure out how to put the data back in the database. We could:

1. Delete everything that is in the database and then write the new data.

2. Overwrite the existing data, disregarding the original content. If we run out of records, we would add new ones; if there were more records originally, we would delete the excess.

3. Hang on to the original key in a hidden field and update/delete based on the original key; then add any new records.

I'm sure we could think of other schemes that might work as well, but the key here is that the logic challenge is not the subfile management, but the batch posting and validation logic. We'll arbitrarily choose the third option here, since the emphasis in this article is on the subfile logic and coding.

Input Subfile Example

Let's take a look at an example. Assume that we have a state abbreviation code table which we want to load into a subfile so that the user can maintain the entire table. The DDS for this file is listed in 8. We update/delete based on the original key and then add new records. To accomplish this, we should hang on to a copy of the record key in a hidden field on the subfile record. This way if the key is changed we know what the original key is.

Let's take a look at an example. Assume that we have a state abbreviation code table which we want to load into a subfile so that the user can maintain the entire table. The DDS for this file is listed in Figure 8. We update/delete based on the original key and then add new records. To accomplish this, we should hang on to a copy of the record key in a hidden field on the subfile record. This way if the key is changed we know what the original key is.

One other caveat: in this example, we won't worry about duplicate entries in the subfile. In a production application, we would either add an edit to ensure that the same state code is not entered twice, or treat the second entry as an update to the first, as more traditional batch processing would handle it.

We want to verify that an abbreviation code is always entered with an accompanying entry for the state name, and vice versa. The messages and subfile field attributes for handling the error conditions have been set up as described in the SFLMSG and SFLMSGID discussion. We have also coded the SFLNXTCHG keyword to re-flag a record as changed when an error is discovered, so that it is read on the next pass of the subfile.

The SFLRCDNBR keyword will position the subfile page to the page of the last error encountered. Note the use of the RRN field associated with the keyword which will also be used in the RPG program as the subfile record number field. The DDS for our sample program appears in 9.

The SFLRCDNBR keyword will position the subfile page to the page of the last error encountered. Note the use of the RRN field associated with the keyword which will also be used in the RPG program as the subfile record number field. The DDS for our sample program appears in Figure 9.

We spelled out each individual technique with examples in the earlier portion of the article so that, at this point, we can look at overall program flow without spending a lot of time picking out the pieces. You should be able to locate each of the earlier techniques and see how they have been woven into the whole-sort of a "Where's Waldo?" challenge.

The HLL program as illustrated in 10 is fairly straightforward until we encounter the logic to replace the database information. As stated earlier, we have a little more to do at this point. The subfile fields and the fields in the database have the same name, which creates a little pas de deux at the point where we want to update. If the hold key was not blank, we either update or delete the old record, based upon whether the state abbreviation has been blanked out. If the hold key was blank, we add the record to the file. The highlighted section of 10 handles the database update. We designed the program so that it updates the database only if you press Enter twice after keying in your changes.

The HLL program as illustrated in Figure 10 is fairly straightforward until we encounter the logic to replace the database information. As stated earlier, we have a little more to do at this point. The subfile fields and the fields in the database have the same name, which creates a little pas de deux at the point where we want to update. If the hold key was not blank, we either update or delete the old record, based upon whether the state abbreviation has been blanked out. If the hold key was blank, we add the record to the file. The highlighted section of Figure 10 handles the database update. We designed the program so that it updates the database only if you press Enter twice after keying in your changes.

Not So Tough After All

This example should give you some idea of where the complexity of the program exists. Subfiles are subfiles! Once you understand the mechanics of a subfile, most of the subfile techniques are not too difficult to master. Although this article covers some advanced techniques, all of the tricky portions of the user interface are removed from the HLL code. To take advantage of them, you simply have to realize they are available and understand their capabilities and limitations.

In our next article, we will examine subfile presentation-multiple-line subfiles, horizontal subfiles, and the use of subfiles within windows as part of a non-destructive interface. We'll also investigate cursor positioning and control to provide a point-and-shoot style of interface.

AS/400 Subfile Programming Part III: Advanced

Figure 1 Sample of subfile with hidden field

 Figure 1: Sample of Subfile with Hidden Field ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A R DETAIL SFL A SELECT 1A I 12 6 A CSNUM R H A CSNAME R O 12 5 A CSCITY R O 12 35 A CSCRLT R O 12 66 ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 
 
 AS/400 Subfile Programming Part III: Advanced
 
 Figure 10 Sample RPG program XRD003RG
 
 FXRD003PFUF E K DISK A FXRD003DFCF E WORKSTN F RRN KSFILE DETAIL *============================================================== * Mainline Code C MOVE '1' *INLR C EXSR LOAD C EXSR DISPLY * C *IN03 IFEQ '0' C *IN12 ANDEQ'0' C EXSR POST C ENDIF *============================================================== * Initilization Routine C *INZSR BEGSR C MOVEA'001000' *IN,31 C WRITEHEADER C MOVEA'110000' *IN,31 C WRITETRAILER C ENDSR *============================================================== * Load Routine C LOAD BEGSR C *IN34 DOWEQ'0' C READ STREC 34 C *IN34 IFEQ '0' C ADD 1 RRN 30 C MOVELSTSTAT HLSTAT C WRITEDETAIL C ENDIF C ENDDO C ENDSR *============================================================== * Display Routine C DISPLY BEGSR C Z-ADD1 RRN 30 C *IN03 DOWEQ'0' C *IN12 ANDEQ'0' C EXFMTHEADER C *IN03 IFEQ '0' C *IN12 ANDEQ'0' * C EXSR PROCES C MOVEA'00' *IN,45 * A blank state abbreviation exists C BLSTAT IFEQ 'YES' C MOVE 1 *IN45 C ENDIF * A blank state name exists C BLNAME IFEQ 'YES' C MOVE 1 *IN46 C ENDIF * Exit when there are no more changes to process C COUNT IFEQ *ZERO C LEAVE C END * C ENDIF C ENDDO C ENDSR *============================================================== * Process Routine C PROCES BEGSR C Z-ADD*ZERO COUNT 20 C MOVE 'NO ' BLSTAT 3 C MOVE 'NO ' BLNAME 3 * Process all changed records C *IN95 DOUEQ'1' C READCDETAIL 95 C *IN95 IFNE '1' C ADD 1 COUNT C MOVEA'00' *IN,35 * Check for a blank state abbreviation code C STSTAT IFEQ *BLANK C STNAME ANDNE*BLANK C MOVE '1' *IN35 C MOVE 'YES' BLSTAT C ENDIF * Check for a blank state name C STSTAT IFNE *BLANK C STNAME ANDEQ*BLANK C MOVE '1' *IN36 C MOVE 'YES' BLNAME C ENDIF * C UPDATDETAIL * C ENDIF C ENDDO C ENDSR *============================================================== * Post the Data Back Routine C POST BEGSR C Z-ADD1 X 30 * Post each record's information back to the original source C *IN95 DOUEQ'1' C X CHAINDETAIL 95 C HLSTAT CHAINSTREC 96 * We have a record to process C *IN95 IFEQ '0' C X CHAINDETAIL 95 * If we had a record, update or delete as appropriate C *IN96 IFEQ '0' C STSTAT IFNE *BLANK C UPDATSTREC C ELSE C DELETSTREC C ENDIF * Write any new records C ELSE C WRITESTREC C ENDIF C ENDIF * C ADD 1 X C ENDDO C ENDSR 
 
 AS/400 Subfile Programming Part III: Advanced
 
 Figure 2 Coding the SFLRCDNBR keyword
 
 Figure 2: Coding the SFLRCDNBR Keyword ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A R HEADER SFLCTL(DETAIL) A OVERLAY A 31 SFLDSP A 32 SFLDSPCTL A 33 SFLCLR A 34 SFLEND A SFLSIZ(0050) A SFLPAG(0010) A RRN 3S 0H SFLRCDNBR(CURSOR) 
 
 AS/400 Subfile Programming Part III: Advanced
 
 Figure 3 Defining the subfile record number
 
 Figure 3: Defining the Subfile Record Number ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 FCSTWRKE CF E WORKSTN F RRN KSFILE DETAIL * C Z-ADD1 RRN 30 
 
 AS/400 Subfile Programming Part III: Advanced
 
 Figure 4 Coding the SFLNXTCHG keyword
 
 Figure 4: Coding the SFLNXTCHG Keyword ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A R DETAIL SFL A 35 SFLNXTCHG 
 
 AS/400 Subfile Programming Part III: Advanced
 
 Figure 5 Using SFLNXTCHG in an RPG program
 
 Figure 5: Using SFLNXTCHG in an RPG Program ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 C *IN95 DOUEQ'1' C READCDETAIL 95 C *IN95 IFNE '1' C ADD 1 COUNT C* C** Test for a valid Part Number C* C OLPART CHAINPARTS 96 C *IN96 IFEQ '1' C MOVE '1' *IN35 C UPDATSTATESFL C MOVE '0' *IN35 C ENDIF C* C ENDIF C ENDDO ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 
 
 AS/400 Subfile Programming Part III: Advanced
 
 Figure 6A Producing error messages
 
 Figure 6a: Producing Error Messages ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A R DETAIL SFL A 35 AO 36 SFLNXTCHG A OLPART R B 6 8 A 35 DSPATR(RI PC) A OLDESC R B 6 16LOWER A 36 DSPATR(RI PC) A OLQTY R B 6 50 A R HEADER SFLCTL(DETAIL) A 45 SFLMSGID(USR0001 *LIBL- A /Messages) A 46 SFLMSGID(USR0002 *LIBL- A /MESSAGES) 
 
 AS/400 Subfile Programming Part III: Advanced
 
 Figure 6B Controlling error message display
 
 Figure 6b: Controlling Error Message Display C *IN95 DOUEQ'1' C READCDETAIL 95 C *IN95 IFNE '1' C ADD 1 COUNT C MOVE '00' *IN35 C* C** Test for a valid Part Number C* C OLPART CHAINPARTS 96 C *IN96 IFEQ '1' C MOVE '1' *IN35 C MOVE '1' *IN45 C ENDIF C UPDATDETAIL C ENDDO C* C** Test for a blank line description C* C OLDESC IFEQ *BLANKS C MOVE '1' *IN36 C MOVE '1' *IN46 C ENDIF C* ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 
 
 AS/400 Subfile Programming Part III: Advanced
 
 Figure 7 How to use SFLINZ and SFLRNA
 
 Figure 7: How to Use SFLINZ and SFLRNA ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A R HEADER SFLCTL(DETAIL) A 31 SFLDSP A 32 SFLDSPCTL A 33 SFLINZ A SFLRNA ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 
 
 AS/400 Subfile Programming Part III: Advanced
 
 Figure 8 Sample database file XRD003PF
 
 A UNIQUE A R STREC A STSTAT 2A A STNAME 30A A K STSTAT 
 
 AS/400 Subfile Programming Part III: Advanced
 
 Figure 9 Sample subfile DDS XRD003DF
 
 A DSPSIZ(24 80 *DS3) A REF(CUSTMST) A PRINT A CA03(03) A CA12(12) A R DETAIL SFL A SELECT 1A I 12 6 A CSNUM R O 12 11 A CSNAME R O 12 23 A CSCRLT R O 12 56EDTCDE(1) A R HEADER SFLCTL(DETAIL) A OVERLAY A SFLSIZ(0050) A SFLPAG(0010) A 31 SFLDSP A 32 SFLDSPCTL A 33 SFLCLR A 34 SFLEND A 1 31'Work with Customers' A DSPATR(HI) A 1 68'Date' A 1 73DATE EDTCDE(Y) A 2 68'Time' A 2 73TIME A 4 2'Position to name:' A @CNAME R B 4 21REFFLD(CSNAME CUSTMST) A 6 2'Type options, press Enter' A COLOR(BLU) A 7 5'5=Display' COLOR(BLU) A 10 10'Customer' DSPATR(HI) A 10 23'Customer' DSPATR(HI) A 10 59'Credit' DSPATR(HI) A 11 5'Opt' DSPATR(HI) A 11 12'No.' DSPATR(HI) A 11 23'Name' DSPATR(HI) A 11 60'Limit' DSPATR(HI) A R TRAILER A 23 2'F3=Exit F12=Cancel' A COLOR(BLU) 

Also Read

Programming in ILE RPG - Defining Data Structures, Part I

H and F Position-less Specs

Practical RPG: AI and IBM i