Subfiles aren't just for displaying data. They're also extremely useful for modifying the data in your data files. As a matter of fact, some of the most powerful subfile programs you'll write are ones that contain update, add, and delete capabilities.
Written by Kevin Vandever
Editor's Note: This article is an excerpt from the book Subfiles in Free-Format RPG.
In this article, you'll learn one way to modify data files using subfiles. This technique lets you update, add, and delete from a name file, which I'll call "Name Master File Maintenance." You can use this program as a template for any name-type master file, such as a customer, salesperson, or vendor file. The program will introduce two DDS keywords, an RPG operation code, and a familiar RPG operation with a new use.
SFLNXTCHG, READC, AFLRCDNBR…And CHAIN and UPDATE, Too
The Subfile Next Change (SFLNXTCHG) keyword is used to mark subfile records as changed. There are times when your program will modify the contents or attributes of a subfile record before displaying the subfile back to the user. If you want IBM i to recognize those changes, use SFLNXTCHG. For instance, let's say the user types some information into a subfile record. To determine its validity, your program interrogates the information. If the information is incorrect, you might want to display an error message and highlight the incorrect field.
Using the SFLNXTCHG keyword, you can mark a subfile record as changed so that no matter what the user does when the subfile is redisplayed on the screen, the program recognizes the record as changed and tries to revalidate it. Without SFLNXTCHG, you could still warn the user something is wrong, but if he or she chooses to ignore the incorrect record, your program has no knowledge that it needs to be revalidated.
You do not need SFLNXTCHG for IBM i to recognize that a user has made a change to a subfile record. The system will mark the subfile record as changed whenever a user changes the data in that record. However, if you want to change data in a subfile record from within your program and mark that record as changed, you need to use SFLNXTCHG in your subfile record format and condition it on an indicator.
The SFLRCDNBR (Subfile Record Number) keyword lets IBM i know which page of data to display. If you have a subfile with 10 pages of data and you want to display record 38 of that subfile, SFLRCDNBR enables you to display the page containing that record. You'll learn more about each of these keywords in the upcoming program.
The last thing I'll introduce at this point that's related to subfiles is the READC operation code. READC reads changed records from a subfile. It reads both records that have been changed by the user and those that are changed in the program and marked as changed by setting on the indicator-conditioning SFLNXTCHG keyword.
The DDS for the subfile (SFL1) and subfile control (SF1CTL) record formats in the Name Master Maintenance program (SFL004DF) look much like those of a self-extending subfile—because that's what it is. In the code in Figure 1, notice that I have no ROLLDN keyword defined in the subfile control record format—IBM i will take care of the rolling down for me. Because SFLSIZ is greater than SFLPAG, the subfile will be allowed to expand if the user wants it to. The OS will handle the paging down, except when new records are added to the subfile. In that case, it will be done by the program.
A R SFL1 SFL
A*
A 74 SFLNXTCHG
A DBIDNM R H REFFLD(PFR/DBIDNM *LIBL/SFL001PF)
A OPTION 1A B 10 3VALUES(' ' '2' '4' '5')
A DBLNAM R O 10 7REFFLD(PFR/DBLNAM *LIBL/SFL001PF)
A DBFNAM R O 10 31REFFLD(PFR/DBFNAM *LIBL/SFL001PF)
A DBMINI R O 10 55REFFLD(PFR/DBMINI *LIBL/SFL001PF)
A DBNNAM R O 10 60REFFLD(PFR/DBNNAM *LIBL/SFL001PF)
A R SF1CTL SFLCTL(SFL1)
A*
A CF06
A SFLSIZ(0013)
A SFLPAG(0012)
A ROLLUP
A OVERLAY
A N32 SFLDSP
A N31 SFLDSPCTL
A 31 SFLCLR
A 90 SFLEND(*MORE)
A RRN1 4S 0H SFLRCDNBR
A 9 7'Last Name'
A DSPATR(HI)
A 9 31'First Name'
A DSPATR(HI)
A 9 55'MI'
A DSPATR(HI)
A 9 60'Nick Name'
A DSPATR(HI)
A 1 2'SFL004RG'
A 1 71DATE
A EDTCDE(Y)
A 2 71TIME
A 1 24'Subfile Program with Update '
A DSPATR(HI)
A 4 2'Position to Last Name . . .'
A PTNAME 20A B 4 30CHECK(LC)
A 9 2'Opt'
A DSPATR(HI)
A 6 2'Type options, press Enter.'
A COLOR(BLU)
A 7 4'2=Change'
A COLOR(BLU)
A 7 19'4=Delete'
A COLOR(BLU)
A 7 34'5=Display'
A COLOR(BLU)
Figure 1: Subfile control and record formats for the Name Master Maintenance program
Notice the SFLNXTCHG and SFLRCDNBR keywords in the code, entered in the subfile record format (SFL). SFLNXTCHG is used in the subfile record format (SFL1) and conditioned with indicator 74. This is the indicator I will manipulate in my RPG program to mark subfile records that have been changed not by the user, but by my program. IBM i marks user changes automatically.
Keyword SFLRCDNBR is used with the relative record number field (RRN1) in the subfile control record (SFLCTL). When you implement SFLRCDNBR, the OS will determine on which page the current relative record number sits and cause your program to display that page. Because I want the user to return to where he or she left off when making a change to a particular subfile record, this will be important.
The other thing you'll notice about the DDS is that it now has something other than output or hidden fields defined in the subfile record format. This program defines a field as "B" for both input and output that allows users to select specific options. Each option corresponds to a specific action to perform in the program. The VALUES keyword tells IBM i the valid options that can be entered. Any other options give a warning error. Now, instead of simply displaying data in the subfile, users have the chance to do something with this data.
Figure 2 shows the screen this DDS will produce. Users have a couple of different options from which to choose. They can scroll through the data or establish a position to somewhere else in the subfile. If the desired data is on the page a user is looking at, he or she can press 2 to edit the record, 5 to display it, or 4 to delete it.
Figure 2: Sample update subfile screen
This brings me to the last new thing about this DDS, which is the second subfile. Yes, you can code multiple subfiles in a display file. However, only 24 of your subfiles can be active at one time, and only 12 can be displayed on a single screen. This second subfile, which is very basic and introduces nothing new, is of the load-all nature. I use it to display a confirmation screen before a user deletes records from the data file. Figure 3 shows the DDS code for this second subfile.
A R SFL2 SFL
A*
A DBIDNM R H REFFLD(PFR/DBIDNM *LIBL/SFL001PF)
A DBLNAM R O 7 3REFFLD(PFR/DBLNAM *LIBL/SFL001PF)
A DBFNAM R O 7 29REFFLD(PFR/DBFNAM *LIBL/SFL001PF)
A*
A*
A R SF2CTL SFLCTL(SFL2)
A*
A SFLSIZ(0016)
A SFLPAG(0015)
A SFLDSP
A 41 SFLCLR
A N41 SFLDSPCTL
A N41 SFLEND(*MORE)
A OVERLAY
A RRN2 4S 0H
A 3 3'Press Enter to confirm your choice-
A s for Delete.'
A COLOR(BLU)
A 4 3'Press F12=Cancel to return to chan-
A ge your choices.'
A COLOR(BLU)
A 6 3'Last Name'
A DSPATR(HI)
A 6 29'First Name'
A DSPATR(HI)
A 1 28'Confirm Delete of Records'
A DSPATR(HI)
Figure 3: Subfile control and record formats for delete confirmation
You've now seen the DDS and sample screen used to let a user update, add, and delete from a name file. In Part 2, we will move on to the RPG code. See you then!
LATEST COMMENTS
MC Press Online