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.
The exciting conclusion--subfiles in windows and more!
In the previous articles in this series, we have explored the basic concepts, implementation and specific coding of subfiles. By now you should have a good feel for what subfiles are-an addressable buffer between your HLL program and your screen that can manage pagination and return selected records to your program.
A classic subfile implementation displays columns of information with fixed headings and one subfile record per row. In this article, we'll focus our attention on subfile presentation-how the subfile contents look on the screen. Depending on the data you are presenting and the users' requirements, one of these techniques may be a much better fit than a traditional columnar subfile. We'll consider multiple-line subfiles, multiple-column subfiles and subfiles displayed within a window. In addition, we'll look at cursor control and determining cursor location, the two techniques necessary for a point-and- shoot style interface.
With the release of V2R2M0 of OS/400 on September 18, several new keywords were made available. We'll cover these enhancements where they are applicable.
Coding Multiple-line Subfiles
Subfiles can be written to give you a series of fields that span several lines instead of fixed columns, or as multi-line columnar data. There is nothing that limits a subfile record to appearing on only one line. These techniques are very useful when more than one line is required to uniquely identify an item displayed in a list. For instance, suppose we display customer number, name and account balance in a subfile on the screen. The possibility exists that multiple companies with the same name might show up on the screen or that one company might have multiple records representing several locations. 1 illustrates a subfile screen that combines several presentation techniques. The first line of each subfile record is aligned under column headings. The second line uses leaders to the left of each field to identify the information.
Subfiles can be written to give you a series of fields that span several lines instead of fixed columns, or as multi-line columnar data. There is nothing that limits a subfile record to appearing on only one line. These techniques are very useful when more than one line is required to uniquely identify an item displayed in a list. For instance, suppose we display customer number, name and account balance in a subfile on the screen. The possibility exists that multiple companies with the same name might show up on the screen or that one company might have multiple records representing several locations. Figure 1 illustrates a subfile screen that combines several presentation techniques. The first line of each subfile record is aligned under column headings. The second line uses leaders to the left of each field to identify the information.
Two keywords exist that allow you to determine whether to show just the first line of each subfile record or all the lines. The one you choose is based upon the way you want the information initially presented. The SFLDROP keyword brings the subfile up in single-line display mode (2) and drops down the additional lines (1) when requested. The SFLFOLD keyword brings the subfile up in multiple-line-per-record form and truncates the additional lines off the screen with the press of an assigned function key.
Two keywords exist that allow you to determine whether to show just the first line of each subfile record or all the lines. The one you choose is based upon the way you want the information initially presented. The SFLDROP keyword brings the subfile up in single-line display mode (Figure 2) and drops down the additional lines (Figure 1) when requested. The SFLFOLD keyword brings the subfile up in multiple-line-per-record form and truncates the additional lines off the screen with the press of an assigned function key.
When either of these keywords is selected, you assign a function key to the keyword. This function then acts as a toggle between the multiple-line display mode and the single-line display mode. For instance, coding SFL-DROP(CA11) initially displays the subfile in truncated form (one line per record) and lets you press F11 to change it to expanded form-and back. When you code the function key with the keyword, you do not have to code the function key at the record level of the display file. The keyword assignment activates that function key.
In order to add this to an existing load-all subfile, we can use SDA to:
1. Add the SFLDROP record-level keyword to the subfile control format.
2. Cut the SFLPAG number in half on the subfile control format.
3. Modify the subfile record format to add additional fields to the display. This can be accomplished by referencing the additional fields from the database and placing them on the second line of the subfile, right on top of what appears to be the second record of subfile information. Once SDA determines that information is to appear on more than one line, it allows multiple lines for each record on the display.
3 contains the DDS for our customer inquiry example. Two additional fields, city and telephone number, with their associated prompt text are added to the subfile record on the second line of the subfile. On the control record, we have added the SFLDROP keyword and have designated F11 to act as the single/multi-line toggle key. The SFLPAG keyword has been cut in half from ten to five, which will accommodate five records in multiple-line mode on the screen at one time (ten records will still be displayed in single-line mode).
Figure 3 contains the DDS for our customer inquiry example. Two additional fields, city and telephone number, with their associated prompt text are added to the subfile record on the second line of the subfile. On the control record, we have added the SFLDROP keyword and have designated F11 to act as the single/multi-line toggle key. The SFLPAG keyword has been cut in half from ten to five, which will accommodate five records in multiple-line mode on the screen at one time (ten records will still be displayed in single-line mode).
Note that all of the work to accomplish this is really a function of the display file. If the data for the additional lines of display is already being retrieved in the HLL program, no modifications have to be made to utilize this function. Simply recompile and watch it work. This is a useful technique with minimal coding. You should consider its use whenever additional information is required for all of the records in the subfile.
Remember, the difference between the SFLDROP and the SFLFOLD keywords is in how the records appear when they are first displayed to the user. SFLFOLD indicates that the multiple-line display should first appear, while SFLDROP indicates that the initial display should be in single-line mode. If you code a multiple-line subfile and neither of these keywords is present, the records always appear in multiple-line mode.
The biggest drawback to the implementation of SFLDROP and SFLFOLD prior to V2R2M0 is that the mode is reset each time the subfile is displayed. In other words, for our example, each time the user selects another name or partial name, the subfile will reset to single-line mode. Coding a single/multiple- line subfile and maintaining a user-selected mode takes a bit more effort. The sidebar on page 74 contains a thorough discussion of techniques to accomplish this using multiple subfiles or, alternately, via the new V2R2M0 subfile enhancements.
Horizontal Subfiles
At the other end of the spectrum from multiple-line subfiles are subfiles that can display more than one record to a line horizontally. To accomplish this, we use the SFLLIN keyword, which specifies the number of spaces between subfile records. Most programmers initially interpret SFLLIN as the number of lines to space between records vertically (i.e., single space, double space). The name of the keyword SFLLIN is easy to misinterpret this way; however, it is the number of spaces between records on the same line. If the information we wish to display on a subfile record is small (10 characters long, perhaps) and we allow one space between records, seven records can appear on one line of the display. 4 illustrates a horizontal subfile.
At the other end of the spectrum from multiple-line subfiles are subfiles that can display more than one record to a line horizontally. To accomplish this, we use the SFLLIN keyword, which specifies the number of spaces between subfile records. Most programmers initially interpret SFLLIN as the number of lines to space between records vertically (i.e., single space, double space). The name of the keyword SFLLIN is easy to misinterpret this way; however, it is the number of spaces between records on the same line. If the information we wish to display on a subfile record is small (10 characters long, perhaps) and we allow one space between records, seven records can appear on one line of the display. Figure 4 illustrates a horizontal subfile.
As a practical example, assume we want to display a list of the valid users on our machine so that someone can look up the ID of another user from within an application. User IDs are only 10 characters long. We do not want to overlay the whole screen to display this list, so we choose to set the subfile size to 42, the subfile page to 21, and the SFLLIN keyword to 1 (see 5). This yields a display with seven records per line but only three lines per page. We take advantage of the OVERLAY and ASSUME keywords to make the display nondestructive (the screen behind this will not be erased).
As a practical example, assume we want to display a list of the valid users on our machine so that someone can look up the ID of another user from within an application. User IDs are only 10 characters long. We do not want to overlay the whole screen to display this list, so we choose to set the subfile size to 42, the subfile page to 21, and the SFLLIN keyword to 1 (see Figure 5). This yields a display with seven records per line but only three lines per page. We take advantage of the OVERLAY and ASSUME keywords to make the display nondestructive (the screen behind this will not be erased).
From the HLL program's perspective, the implications of SFLLIN do not matter. There is no difference in the program code, whether there is one record per line or seven. The program simply loads the available records and then displays the subfile control record (HEADER), along with its associated detail, to the screen. The subfile records are displayed in columnar fashion- record 1 appears in the first row of column 1, record 2 appears in the second row of column 1, record 3 in the third row of column 1, record 4 in the first record of column 2, and so forth.
The SFLLIN keyword has no effect on the standard cursor tracking on the screen. The cursor moves left to right, top to bottom. If these fields were input capable, tabbing or field exiting from the first record of the first row would go to the first record of column two, which is actually the fourth record of the subfile!
Subfiles in Windows
The previous example provided our first encounter with a subfile that does not occupy the entire screen. Prior to V2R1M0, subfiles always cleared the entire line that the subfile occupied. A nondestructive subfile could be coded using the technique described for horizontal subfiles, but there was no way to show a subfile that was less than full screen width. Other coding techniques had to be used to display a scrollable list that did not occupy the entire 80- or 132-character line.
The advent of V2R1M0 made the WINDOW and WDWBORDER keywords available, providing a way of coding a subfile that does not occupy the entire line. However, specifying the WINDOW keyword does not automatically make the panel nondestructive. Two typical techniques for displaying nondestructive panels are the USRDSPMGT keyword and the ASSUME keyword. Subfiles cannot be used when USRDSPMGT is employed, so the ASSUME keyword is our choice.
We would like to present a list of customers much like we did with earlier versions of customer subfiles. This time, we format the screen in a much more compressed fashion. The user will have a position-to capability to locate a customer by name. Once the customer name appears on the screen, the user can select it by placing the cursor on it and pressing the Enter key.
The window we're designing appears in 6. The DDS for the subfile, shown in 7, changes very little from a regular subfile. The DETAIL record serves as the subfile, and the HEADER is the subfile control record with our standard set of six subfile keywords and a field to allow the user to position the file. The TRAILER record contains constants to be displayed at the bottom of the subfile display.
The window we're designing appears in Figure 6. The DDS for the subfile, shown in Figure 7, changes very little from a regular subfile. The DETAIL record serves as the subfile, and the HEADER is the subfile control record with our standard set of six subfile keywords and a field to allow the user to position the file. The TRAILER record contains constants to be displayed at the bottom of the subfile display.
In addition to the standard keywords, we have added a WINDOW keyword to both the HEADER and TRAILER panels. Because TRAILER will be the first format displayed by the HLL program, it must define the window. The window starts on line 4 at position 5 for 18 lines of 45 characters. Coding the WINDOW keyword on the HEADER record indicates that it (and its associated subfile) co- occupies the window established by TRAILER.
We also add a fourth record named DUMMY to carry the ASSUME keyword. This is a wise practice when coding windows, since the ASSUME keyword can clash on a record with certain other keywords. Provided that at least one record of a display file has the ASSUME keyword coded, all the panels of the file become nondestructive. This allows us to display the subfile in a window and restore the underlying screen when the user completes his subfile search.
Nothing in the HLL code tells us the subfile is in a window; that is purely a product of keywords in the display file itself. The special coding comes in the determination of the subfile record that the user selects and is illustrated by the code fragment in 8. We use two separate pieces of information gathered from the file information data structure that we associate with our display file. From positions 370 and 371, we get the cursor position when the user pressed Enter. Positions 378 and 379 tell us the record number of the top record in the subfile that is currently on the screen. Both are two-byte binary numbers. The location of these fields was found in the RPG Reference manual and the Data Management Guide. (There are a number of other tasty bits of information in the file information data structure.)
Nothing in the HLL code tells us the subfile is in a window; that is purely a product of keywords in the display file itself. The special coding comes in the determination of the subfile record that the user selects and is illustrated by the code fragment in Figure 8. We use two separate pieces of information gathered from the file information data structure that we associate with our display file. From positions 370 and 371, we get the cursor position when the user pressed Enter. Positions 378 and 379 tell us the record number of the top record in the subfile that is currently on the screen. Both are two-byte binary numbers. The location of these fields was found in the RPG Reference manual and the Data Management Guide. (There are a number of other tasty bits of information in the file information data structure.)
The cursor location contains the row in the left byte and the column in the right byte; for this application, we are only interested in the row. Our HLL language does not allow us to define a one-byte binary number, so we define it as a two-byte number and do some simple arithmetic to get what we are after. We extract the row by dividing by 256 which is the decimal equivalent of hexadecimal 100. This shifts the hexadecimal value two positions to the left. For example, if the row is seven and the column is 12 the hexadecimal value of the 2-byte binary field would be 070C. Dividing this value by hexadecimal 100 (decimal 256) yields 07, the row number: 070C _ 100 = 07
Once the row number is determined, we check to see if it was located at one of the lines of the subfile. If so, we compute the subfile record number by calculating how many rows into the subfile the cursor is and adding the result to the subfile record number currently at the top of the display. With the selected subfile record computed, we simply chain to that record of the subfile to get the associated customer number. The rest of the HLL program is a standard subfile program such as we've used in the previous articles of this series.
Good news for those who found the computation of the record number a bit cryptic-in V2R2M0, the new keyword SFLCSRRRN can be used to identify the relative record number of the subfile where the cursor is located. This keyword has a hidden field associated with it that returns the RRN to your program.
Subfile Performance
Subfile programs that perform well are programs that don't do anything superfluous. If users can find what they need within a page or two of the search, by all means don't load a lot of records they won't need. If you don't need to refresh the subfile constantly because of volatile data, don't automatically refresh; provide a refresh key instead. When you are reading back from the subfile, read only changed records or, in the case of an input- capable subfile, only active records.
The choice of a proper subfile size is important. The subfile size determines the initial space allocation set aside to hold the subfile records. If you make this too small and add more records to the subfile than initally set, your subfile records will be loaded into noncontiguous spaces. If you make it too large and never use all of the space, your Process Access Group (PAG) will be larger than it needs to be. A PAG is a group of job related objects that can be paged in and out of storage. If you allow the subfile to expand and don't control how many pages a user can load, your PAG can get very large and will peform poorly.
In short, follow these three rules:
1. Provide good search criteria so that users can locate what they need in a page or two of subfile records.
2. Don't load an unwieldy number of subfile records.
3. Load, refresh and process only when you need to.
If you follow these basic rules, your subfiles should perform efficiently.
Wrap-up
We've gone quite a way in this four-article set, from understanding the fundamentals of subfiles to coding the three basic forms-load-all, expanding and page-at-a-time. We've looked at using subfiles for input, subfile formatting, various subfile techniques and now subfiles in a nondestructive interface. COBOL programmers, take heart. All of these techniques are available to you as well; we simply stuck with one illustrative HLL language because of space limitations.
If you review all of the techniques and capabilities demonstrated, you'll see that most of the work is accomplished in the display file itself. Once you understand the basic set of processes that must occur in any subfile program, the HLL code changes very little to accomplish a whole bevy of effects that have become central to a native interface. We hope this series has been fun as well as instructive, and most importantly, will be useful in your daily work.
The Ins and Outs of SFLFOLD and SFLDROP
The SFLDROP/SFLFOLD keywords are very simple to use, allowing you to display subfile records in single-line or multi-line formats and to alternate between the two. For example, the result of an initial search might yield a list of customer names and credit limits. Once the correct group of customers is isolated, the user can expand each line to show the city and telephone number. This allows the initial search to be faster, since more customers can be displayed on the screen at one time, but gives the user the ability to display more information, if necessary, to identify the correct customer.
Prior to V2R2M0, the problem with SFLDROP and SFLFOLD is that if the user switches from one mode to another, the mode is lost whenever the subfile is redisplayed. This appears to the user as if the program arbitrarily changes the display without being told to do so. This flip-flopping of modes can be eliminated in V2R2M0 by coding both the SFLDROP and the SFLFOLD keywords on the subfile control record and using a single option indicator as a mode toggle. (Prior to V2R2M0, option indicators are not allowed on SFLDROP/SFLFOLD, and both keywords cannot be used on the same record.) A new keyword (SFLMODE) must be used in conjunction with SFLDROP and SFLFOLD to learn the mode of the display when the user pressed Enter. This information is then used to set the option indicator. See Figures A1 and A2 for an example of the V2R2M0 code.
If you are feeling cautious about installing V2R2M0, there is a way to overcome the limitations of SFLDROP and SFLFOLD without losing the mode of the search. Assume we want to code the customer search example and maintain a mode of display even when a new search is entered. We accomplish this with two separate subfiles. They contain the same records and are loaded at the same time. One subfile contains the additional lines.
The F11 key is enabled, and a subfile record number will be coded on each subfile. A3 shows the DDS for the first subfile and the trailer record; the second subfile is a duplicate of the first with the addition of the city and zip code information on the second line of the detail record. The record names for the second subfile are HEADER2 (for the control record) and DETAIL2 (for the subfile record).
The F11 key is enabled, and a subfile record number will be coded on each subfile. Figure A3 shows the DDS for the first subfile and the trailer record; the second subfile is a duplicate of the first with the addition of the city and zip code information on the second line of the detail record. The record names for the second subfile are HEADER2 (for the control record) and DETAIL2 (for the subfile record).
In the associated HLL program, we keep track of which subfile to present via a working variable called MODE. The contents of MODE will toggle between "Expand" or "Shrink." To keep the two subfiles synchronized, we use the same relative record number field for both subfiles and then just write to both subfiles in the load routine. Based upon the mode, we will either display HEADER and DETAIL or HEADER2 and DETAIL2.
Next we have to synchronize the two subfiles so that if a user rolls to a particular page in one subfile and presses F11 to get to the other, the same data is displayed. This is done by coding the SFL-RCDNBR on both subfile control records with the RRN field associated with both subfiles in the RPG program. We can determine the page of the subfile via the file information data structure in positions 377 and 378. This returns the lowest record number on the screen for the most recently displayed subfile. By Z-ADDing this number to RRN before displaying the other subfile, we ensure the appropriate page is displayed. The relevant parts of the RPG/400 code are shown inA4-A7. Logic similar to the DISPLY subroutine in A7 is used to process records the user selects from either subfile.
Next we have to synchronize the two subfiles so that if a user rolls to a particular page in one subfile and presses F11 to get to the other, the same data is displayed. This is done by coding the SFL-RCDNBR on both subfile control records with the RRN field associated with both subfiles in the RPG program. We can determine the page of the subfile via the file information data structure in positions 377 and 378. This returns the lowest record number on the screen for the most recently displayed subfile. By Z-ADDing this number to RRN before displaying the other subfile, we ensure the appropriate page is displayed. The relevant parts of the RPG/400 code are shown in Figures A4-A7. Logic similar to the DISPLY subroutine in Figure A7 is used to process records the user selects from either subfile.
Considering what we are pulling off here-an unequal list of records that remains synchronized while you roll through either-the amount and complexity of code is not too bad. The trickiest part is figuring out how to get the page of the subfile back from the file information data structure.
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure A1 DDS in V2R2M0
Figure A1: DDS in V2R2M0 ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A R HEADER SFLCTL(DETAIL) A 35 SFLFOLD(CA11) A N35 SFLDROP(CA11) A MODE 1 0H SFLMODE
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure A2 RPG in V2R2M0
Figure A2: RPG in V2R2M0 ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 C* C** Determine the mode of the subfile, and set the toggle C* C MODE IFEQ *OFF C MOVE *OFF *IN35 C ELSE C MOVE *ON *IN35 C ENDIF
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure A3 Partial DDS for synchronized subfile
Figure A3: Partial DDS for Synchronized Subfile ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 A DSPSIZ(24 80 *DS3) A REF(*LIBL/CUSTMST CUSTREC) A PRINT A CA03(03) A CA11(11) 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 56 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 3 0H SFLRCDNBR A 2 2'CSTWRKA' A 2 26'Work With Customers' A DSPATR(HI) A 2 64'Date' A DSPATR(HI) A 2 70DATE A EDTCDE(Y) A 3 64'Time' A DSPATR(HI) A 3 70TIME A 4 4'Position to name...' A DSPATR(HI) A @CNAME R B 4 24REFFLD(CUSTREC/CSNAME *LIBL/CUSTMST) A 6 3'Type options, press Enter.' A DSPATR(HI) A 8 5'5=Display' A DSPATR(HI) A 10 5'Opt Customer Customer - A Credit - A ' A DSPATR(HI) A 11 5' No. Name - A Limit - A ' A DSPATR(HI) A DSPATR(UL) A R TRAILER A 22 5' - A - A ' A DSPATR(UL) A DSPATR(HI) A 23 5'F3=Exit' A DSPATR(HI) A 23 14'F11=Expand/Condense' A DSPATR(HI) A 23 35'F12=Cancel' A DSPATR(HI) ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure A4 F and I-specs for synchronized subfiles
Figure A4: F and I-Specs for Synchronized Subfiles ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 FCSTWRKF CF E WORKSTN F RRN KSFILE DETAIL F RRN KSFILE DETAIL2 F KINFDS WRKDS IWRKDS DS I B 378 3790CRRN ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure A5 Change screen modes
Figure A5: Change Screen Modes ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 C *IN11 IFEQ *ON C MODE IFEQ 'Expand' C MOVEL'Shrink' MODE C ELSE C MOVEL'Expand' MODE C ENDIF C Z-ADDCRRN RRN C ENDIF ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure A6 Load both subfiles
Figure A6: Load Both Subfiles ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 C************************************************************** C* Subroutine Name: LOAD C* Purpose: Load the Subfile C************************************************************** C LOAD BEGSR C* C *IN34 DOUEQ*ON C *IN95 OREQ *ON C READ CUSTREC 34 C *IN34 IFEQ *OFF C ADD 1 RRN C WRITEDETAIL 95 C WRITEDETAIL2 95 C ENDIF C ENDDO C* C Z-ADD1 RRN C ENDSR ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure A7 Display the active subfile
Figure A7: Display the Active Subfile ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 C************************************************************** C* Subroutine Name: DISPLY C* Purpose: Display the HEADER/DETAIL C************************************************************** C DISPLY BEGSR C* C** Set the subfile display indicator if records are loaded C* C RRN IFNE 0 C MOVE *ON *IN31 C ENDIF C* C MODE IFEQ 'Shrink' C EXFMTHEADER C ELSE C EXFMTHEADER2 C ENDIF C* C ENDSR ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure 1 Multi-line customer subfile display
Figure 1: Multi-line Customer Subfile Display CSTWRKA Work With Customers Date 7/15/92 Time 15:53:55 Position to name... A_____________________________ Type options, press Enter. 5=Display Opt Customer Customer Credit No. Name Limit _ 150 Alliance Gas Co. 60000.00 City: Richmond Zip Code: 06575 _ 950 Anaconda Supplies Inc. 300000.00 City: Stamford Zip Code: 06580 _ 550 Autocut Distributors Inc. 54000.00 City: Fairlane Zip Code: 05674 _ 900 Boxcar Supplies Inc. 300000.00 City: Mount Ridge Zip Code: 16580 _ 500 Distrends Inc. 54000.00 City: Margot Zip Code: 15674 + F3=Exit F11=Expand/Condense F12=Cancel
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure 2 Single-line customer subfile display
Figure 2: Single-line Customer Subfile Display CSTWRKA Work With Customers Date 7/15/92 Time 15:45:12 Position to name... A_____________________________ Type options, press Enter. 5=Display Opt Customer Customer Credit No. Name Limit _ 150 Alliance Gas Co. 60000.00 _ 950 Anaconda Supplies Inc. 300000.00 _ 550 Autocut Distributors Inc. 54000.00 _ 900 Boxcar Supplies Inc. 300000.00 _ 500 Distrends Inc. 54000.00 _ 100 Duplo Products, Inc. 60000.00 _ 200 Dynopipe Inc. 50000.00 _ 250 Ever Ready Pipes Inc. 50000.00 _ 300 Fabricators Unlimited Inc. 75000.00 _ 1000 Integrated Dynamics Inc. 275000.00 + F3=Exit F11=Expand/Condense F12=Cancel
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure 3 Partial DDS for single-line/multi-line subfile
Figure 3: Partial DDS for Single-line/Multi-line Subfile ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 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 56 A 13 13'City:' A DSPATR(HI) A CSCITY R O 13 19 A 13 47'Zip Code:' A DSPATR(HI) A CSZIP R O 13 57 A R HEADER SFLCTL(DETAIL) A OVERLAY A SFLDROP(CA11) A 31 SFLDSP A 32 SFLDSPCTL A 33 SFLCLR A 34 SFLEND A SFLSIZ(0050) A SFLPAG(0005) ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure 4 Sample horizontal subfile
Figure 4: Sample Horizontal Subfile PROFLS User Profile List CABRINA CTUNG GEORGE_W MONIQUE PGMR2 QDBSHR QDSNX CLIONARA GAYLE JULIUS MOONCHILD PGMR3 QDFTOWN QFNC CORBIN GENERAL JOHN MPQR2 PS2 QDOC QGATE +
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure 5 Partial DDS for a horizontal subfile
Figure 5: Partial DDS for a Horizontal Subfile ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A R DETAIL SFL A UPUPRF R O 2 3 A R HEADER SFLCTL(DETAIL) A OVERLAY A 31 SFLDSP A 32 SFLDSPCTL A 33 SFLCLR A 34 SFLEND A SFLSIZ(0042) A SFLPAG(0021) A SFLLIN(0001) A R DUMMY ASSUME A 17 1' ' ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure 6 Customer selection window
Figure 6: Customer Selection Window ................................................. : CSTWRKW Customer Selection Date 8/21/92 : : Time 18:41:13 : : Position To: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB : : : : Number Name : : 000000 000000000000000000000000000000 : : 000000 000000000000000000000000000000 : : 000000 000000000000000000000000000000 : : 000000 000000000000000000000000000000 : : 000000 000000000000000000000000000000 : : 000000 000000000000000000000000000000 : : 000000 000000000000000000000000000000 : : 000000 000000000000000000000000000000 : : 000000 000000000000000000000000000000 : : 000000 000000000000000000000000000000 + : : : : F3=Exit F12=Cancel : : : :...............................................:
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure 7 DDS for a windowed subfile
Figure 7: DDS for a Windowed Subfile ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A DSPSIZ(24 80 *DS3) A REF(*LIBL/CUSTMST CUSTREC) A PRINT A CA03(03) A CA12(12) A R DETAIL SFL A CSNUM R O 6 1 A CSNAME R O 6 10 A R HEADER SFLCTL(DETAIL) A SFLSIZ(0050) A SFLPAG(0010) A OVERLAY A 31 SFLDSP A 32 SFLDSPCTL A 33 SFLCLR A 34 SFLEND A WINDOW(TRAILER) A 1 1'CSTWRKW' A 1 12'Customer Selection' A DSPATR(HI) A 1 33'Date' A DSPATR(HI) A 1 38DATE A EDTCDE(Y) A 2 33'Time' A DSPATR(HI) A 2 38TIME A 3 1'Position To:' A DSPATR(HI) A @CNAME R B 3 14REFFLD(CSNAME) A 5 1'Number Name' A DSPATR(HI) A R TRAILER A WINDOW(4 5 18 45) A 17 1'F3=Exit' A DSPATR(HI) A 17 10'F12=Cancel' A DSPATR(HI) A R DUMMY ASSUME A 17 1' ' ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
AS/400 Subfile Programming Part IV: Fine-Tuning
Figure 8 Finding cursor postion for SFL record selection
Figure 8: Finding Cursor Position for Subfile Record Selection ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 FCUSTNAMEIF E K DISK FCSTWRKW CF E WORKSTN F RRN KSFILE DETAIL F KINFDS WRKDS IWRKDS DS I B 370 3710CSRLOC I B 378 3790CRRN C************************************************************** C* Subroutine Name: PROCES C* Purpose: Determine the User's Selection C************************************************************** C PROCES BEGSR C* C** Determine the Cursor Location C* C CSRLOC DIV 256 #ROW 30 C MVR #COLUM 30 C #ROW IFGE 10 C #ROW ANDLE19 C* C** If it's in the area, determine the RRN C* C #ROW SUB 10 SRRN 30 C CRRN ADD SRRN SRRN C* C** If its not beyond the last RRN loaded, get the customer C* C SRRN IFLE RRN C SRRN CHAINDETAIL 90 C MOVE 'Yes' @SELCT C ENDIF C ENDIF C* C ENDSR ... 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