Saving coding effort and create consistent multi-record displays.
by Jonathan Yergin
The order entry operator for Best Distributors is giving your new program its first live test. You are on standby to trouble-shoot any problems. Perhaps you are a beginning programmer, fresh out of school, putting theories into practice. Or maybe you are a veteran S/3X programmer who has just written your first native application on the new AS/400. Your boss is standing by as well, to review the results of the test.
A buyer from ABC Paint Supply calls to order paint from the Premium Paint Company. The operator is on the first screen and needs to know the Vendor Number. She presses the function key for Alpha Search and is prompted for a search value. She keys "Premium" and presses the enter key. After being presented with a scrolling list of vendors, she selects Premium Paint Company by placing an "X" in the selection field next to it. Then she presses the enter key again, and is returned to the original screen where Vendor Number has been filled in.
Since the buyer who is calling knows Best Distributor's item numbers, the operator quickly keys twenty or so items and their quantities on one screen. She presses the function key for review mode and reads back the order. There are two errors. The quantity is wrong on line 5, and the wrong item was entered on line 10. The transactions in error are selected for update and deletion by placing a "U" and "D" beside lines 5 and 10. After making corrections the operator confirms the order for the buyer. Her evaluation of your new program is concise: "I like it."
All of these functions - inquiry, search, selection, transaction entry and transaction review - can be implemented easily with subfiles. A subfile is a way to work with a group of like records for display and processing, much like a direct file in memory. The records are displayed in rows, several to a page, one page at a time. You define how many records to display on a page and how many pages of records to place in the subfile. The record fields can be input-only, output-only or input-output. 1 illustrates one page of a subfile display.
All of these functions - inquiry, search, selection, transaction entry and transaction review - can be implemented easily with subfiles. A subfile is a way to work with a group of like records for display and processing, much like a direct file in memory. The records are displayed in rows, several to a page, one page at a time. You define how many records to display on a page and how many pages of records to place in the subfile. The record fields can be input-only, output-only or input-output. Figure 1 illustrates one page of a subfile display.
In a typical subfile application, several pages of subfile records are written to memory; then a write/read is executed for the subfile control format. The operating system takes over to display the records on the screen and to respond to the roll keys by paging the display. You can roll back and forth to display each page. Selection of displayed records for further processing is simple: you can set up a selection field for each record into which a selection character is keyed. When you press enter or a defined command key, control is returned to the high-level language (HLL) program.
Building the Display File
To build a subfile program, we must first design and create a display file. At least two display formats must be defined in the data description specifications (DDS): the subfile record format, with the SFL record level keyword; and the subfile control record format, with the SFLCTL record level keyword. The subfile record format defines the fields in the records that are written to memory, while the subfile control record format defines how the subfile can be displayed, cleared, deleted, and initialized.
The subfile record format with its associated field descriptions must be defined immediately before the subfile control record format. Displayable fields in the subfile format are generally the same as fields in other display formats. The fields in the sample display format (4) are all output only. The locations specified for the fields are the locations on the screen where the first subfile record will be displayed. Most field- level keywords are allowed for subfile fields. The exceptions are DATE, TIME, ERRMSG, and ERRMSGID. We veteran S/3X programmers appreciate the use of the keywords EDTCDE and EDTWRD. The ease of formatting they provide was formerly only available using formats with a variable starting line number. Subfiles also provide the professional look of programs that use an array to provide a virtual screen buffer. In fact subfiles may be compared to a dynamically allocated array of formatted data.
The subfile record format with its associated field descriptions must be defined immediately before the subfile control record format. Displayable fields in the subfile format are generally the same as fields in other display formats. The fields in the sample display format (Figure 4) are all output only. The locations specified for the fields are the locations on the screen where the first subfile record will be displayed. Most field- level keywords are allowed for subfile fields. The exceptions are DATE, TIME, ERRMSG, and ERRMSGID. We veteran S/3X programmers appreciate the use of the keywords EDTCDE and EDTWRD. The ease of formatting they provide was formerly only available using formats with a variable starting line number. Subfiles also provide the professional look of programs that use an array to provide a virtual screen buffer. In fact subfiles may be compared to a dynamically allocated array of formatted data.
The subfile control record format must specify a subfile record format as the parameter for the SFLCTL keyword and must immediately follow the subfile record format. It may contain field descriptions as well as subfile control keywords. The following is a summary of the subfile keywords used in our sample display file.
Required keywords: SFLDSP, SLFDSPCTL, SFLSIZ, and SFLPAG. Optional keywords: SFLCLR, SFLEND, SFLRCDNBR, and SFLDROP.
The SFLDSP keyword signals the operating system to display the subfile when your HLL program performs an output operation to the subfile control format. An option indicator is normally used with this keyword. In our sample program, indicator 20 is set on to display the subfile. If no records are written to the subfile, we set indicator 20 off.
The SFLDSPCTL keyword signals the operating system to display the fields in the subfile control record when your HLL program issues an output operation to it. This keyword must be in effect when an input operation is performed, and an option indicator is normally used. In our sample program, this keyword is enabled when indicator 98 is set off. It is a common practice to condition the SFLCLR keyword with the opposite indicator setting.
The SFLSIZ keyword is used to specify the number of records in the subfile. When subfile size is greater than subfile page, and your program writes a record to the subfile with a relative record number larger than subfile size, the subfile is automatically extended. Subfile size is one larger than subfile page in our sample program, so we can write any number of subfile records up to the maximum allowed by the system (9999).
The SFLPAG keyword specifies the number of subfile records to be displayed at one time. The number of lines required to display a page of records is found by multiplying the subfile page value by the number of lines required to display one record. In the sample program, we begin with a subfile size of 16 and with a record that is displayed on one line.
The SFLCLR keyword signals the operating system to clear all records from the subfile. An option indicator is required to prevent clearing the subfile on every output operation to the subfile control format. As stated above, it is common practice to condition this keyword with the opposite indicator setting used to condition the SFLDSPCTL keyword. In our sample program, indicator 98 is set on to enable subfile clear, a write operation is issued to the subfile control format, then indicator 98 is set off to enable the subsequent display of the subfile control record. In general, a subfile is loaded by incrementing the subfile relative record number while writing subfile records. To restart this process, for example after a new search value has been selected, it is necessary to first clear all active records from the subfile.
The SFLEND keyword is used to enable the display of a plus sign (+) in the lower right corner of the subfile area. The plus sign signals the display station operator that the roll-up key may be used to display more records. An option indicator is required. When subfile size does not equal subfile page, the operating system responds to the roll keys by paging the display, and displays the plus sign as long as there are more pages. When the last page is displayed, the plus sign appears if the option indicator is off and does not appear if the option indicator is on. The sample program uses indicator 90, the EOF indicator, to condition SFLEND. Therefore, the only time the plus sign will not appear is when the data file has reached EOF.
The ROLLUP keyword is used in our sample display file. It is conditioned by the opposite indicator setting used to condition SFLEND. Thus the roll-up key is enabled when indicator 90 is off and the plus sign is displayed, but is disabled at EOF when the plus sign is not displayed. Because the plus sign is displayed on the last page of the subfile when the operating system cannot page the subfile any further, our program must provide for further paging. When the roll-up key is pressed again, our program receives control and adds another page of records to the subfile, then uses SFLRCDNBR to display the new page.
The SFLRCDNBR keyword is a field-level keyword used to specify the page of a subfile to be displayed. The page to be displayed will be the one which contains the subfile record number that is loaded into SFLRCDNBR. The subfile record number field must be signed numeric (S in position 35) and up to four digits in length with zero decimal positions. The field must be defined as output-only, as both input and output, or as a hidden field. Our sample display file uses the hidden field SFLPOS (H in position 38), as the subfile record number field. The relative record number of the last record written to the subfile is placed in this field. Thus the last page written to the subfile is always displayed first.
The SFLDROP keyword assigns a CA or CF key, which when pressed, displays a multi-line subfile record alternately in single-line or multi-line format. We will add this function to our program after first compiling the program without it. The benefits of using the SFLDROP keyword are explained later in the detailed discussion of the sample program.
The Plan for a Simple RPG Inquiry Program
There are three steps to loading and displaying a subfile for a simple RPG inquiry program. First, clear the subfile. Second, read the database file and write records to the subfile. And third, write/read the subfile control format. This process is illustrated in more detail by the pseudocode in 2a.
There are three steps to loading and displaying a subfile for a simple RPG inquiry program. First, clear the subfile. Second, read the database file and write records to the subfile. And third, write/read the subfile control format. This process is illustrated in more detail by the pseudocode in Figure 2a.
The sample master file inquiry program displays data from the Vendor Master file. A vendor name or partial name is entered as a search value and a list of vendors is displayed. The DDS for file VENDPF is listed in 3a. The UNIQUE keyword prevents duplicate vendor numbers. The Vendor Master is accessed by vendor name through logical file VENDLF, listed in 3b. Vendor Number is included in the key to differentiate between entries with duplicate vendor names.
The sample master file inquiry program displays data from the Vendor Master file. A vendor name or partial name is entered as a search value and a list of vendors is displayed. The DDS for file VENDPF is listed in Figure 3a. The UNIQUE keyword prevents duplicate vendor numbers. The Vendor Master is accessed by vendor name through logical file VENDLF, listed in Figure 3b. Vendor Number is included in the key to differentiate between entries with duplicate vendor names.
The display file SFL001DF (4) contains four record formats: a header record, a subfile record, a subfile control record, and a footer or command key record. The fields in the subfile format are linked to the fields in the physical file by the fact the same name is used for both. No moves are required while the RPG program is loading the subfile. Notice the BLINK keyword in the subfile control record format. It is a good practice to specify BLINK on the last format displayed, in order to match the blink attributes of the operating system displays. You will notice that some lines in the display file source have been "commented out." Go ahead and enter them as comments and we will enable them later.
The display file SFL001DF (Figure 4) contains four record formats: a header record, a subfile record, a subfile control record, and a footer or command key record. The fields in the subfile format are linked to the fields in the physical file by the fact the same name is used for both. No moves are required while the RPG program is loading the subfile. Notice the BLINK keyword in the subfile control record format. It is a good practice to specify BLINK on the last format displayed, in order to match the blink attributes of the operating system displays. You will notice that some lines in the display file source have been "commented out." Go ahead and enter them as comments and we will enable them later.
We offer the RPG program (5) as a model for interactive programming. Though its scope is quite limited, its structure provides for quick and convenient modification or enhancement. There is a program initialization subroutine (ZFIRST), a program exit subroutine (ZEXIT), and a relatively small main processing section. The function of the initialization and exit routines in our program is to move a value to the next screen field which controls both the screen processing loop and the screen selection case.
We offer the RPG program (Figure 5) as a model for interactive programming. Though its scope is quite limited, its structure provides for quick and convenient modification or enhancement. There is a program initialization subroutine (ZFIRST), a program exit subroutine (ZEXIT), and a relatively small main processing section. The function of the initialization and exit routines in our program is to move a value to the next screen field which controls both the screen processing loop and the screen selection case.
Each screen (there is only one in this case) has a display and processing subroutine. This routine calls a subroutine to build the screen, displays the header and command key formats, then begins the screen display loop. The screen display loop continues while the screen display indicator is on. The indicator is set off just after the loop begins, and must be set on explicitly to display the screen again. The primary display format is written and then read. When control is returned to the program, the screen processing case branches to a function-key-processing subroutine. With this modular design, function keys may be added easily, and a maintenance programmer will know where to go if asked to modify the processing for a particular function key.
The "work horse" routine in our program is the roll-up processing routine, FM01RU. The pseudocode for that routine is listed in 2b. Notice the similarities to the pseudocode for a simple inquiry program. The major difference is that this routine reads a maximum of 16 records, rather than reading until EOF.
The "work horse" routine in our program is the roll-up processing routine, FM01RU. The pseudocode for that routine is listed in Figure 2b. Notice the similarities to the pseudocode for a simple inquiry program. The major difference is that this routine reads a maximum of 16 records, rather than reading until EOF.
Putting It Together
Create the physical and logical files, VENDPF and VENDLF. Use a program or utility to add records to the physical file. You should have at least 100 records in the file to observe the subfile program effectively. Create the display file and the RPG program, then call the program and test its features.
Enter a search value for a name close to the beginning of the file, such as "A". A list of vendors will be displayed. Add two pages to the subfile by pressing the roll-up key. Observe the slight delay as the program adds records to the subfile. Now page back by pressing the roll-down key twice. Page forward again the same number of frames. These operations are handled by the operating system and should execute quickly. Now page forward and you should again notice a slight delay.
To observe the end-of-file condition, enter a search value to position the file near the end, such as "Y". When you reach EOF, the plus sign will no longer appear in the lower right corner of the display. The roll-up key will not return control to your program, but will generate a message.
Go Ahead, Drop Your Subfile...
One of my favorite features of subfile inquiry programs is the SFLDROP keyword - it provides so much function for so little programming effort. This keyword assigns a function key which, when pressed, alternates between a multi-line and single-line display.
Imagine that you have just created a "Vendor Lookup" program, like our sample, on the System/36. Or that you wrote a program to do the same thing in BASIC on a PC. You are displaying the city, state and zip code fields to help find the correct vendor. A request has been approved to add fields to the display that are needed for other purposes. The fields are the two address lines and the phone number. Since only half as many lines can be displayed with this information added, the display of the extra fields will be controlled by a function key. Think of the programming required: add fields to the display; check the condition of the function key, and display fields based on that condition; and adjust the roll value used based on the same condition.
We will add this function to our program by defining the fields in the display file, and by defining the command key with the SFLDROP keyword. You can do this by removing the asterisks in the display file, and by changing the subfile size and page values - SFLSIZ(9) and SFLPAG(8). Now re-create the display file and the program. That's all. No changes are necessary to the RPG source code.
Each time the subfile is displayed, the records will be displayed in their truncated format, 16 lines per page. Press function key 11, and the records will be displayed in folded format, eight per page. The operating system "knows" what format it is displaying and responds correctly to the roll keys.
But Avoid These Pitfalls
There are many ways to produce errors while writing a subfile program. This is one reason programmers become frustrated with their first attempts. I will cover a number of these situations, and give you instructions to modify the original display file or program source to create the error. But why create an error? You will actually observe the error condition and see how it is fixed. The goal is for you to remember the fix when the error occurs again.
The subfile control record format must specify a subfile record format as the parameter for the SFLCTL keyword and must immediately follow the subfile record format. An error will occur if you attempt to create our sample display file with the subfile record formats in reverse order.
If your program issues an output operation to the subfile control record format when the SFLDSP keyword is in effect, and no active records are in the subfile, an error message is sent to your program. To demonstrate this error condition, change the second of the following two lines from the FM01RU subroutine:
SFLRN1 IFEQ *ZEROS MOVEA'10' *IN,20
Now if you select a search value with no associated records, such as "ZZZ", your program will attempt to display the empty subfile, and cause the error.
The SFLDSPCTL keyword must be in effect when an input operation is requested from the subfile control record format. This is true even if the record contains no input fields. To produce this condition, specify indicator 97 for the SFLDSPCTL keyword. Since indicator 97 is never on, the EXFMT operation will produce an error.
If your program issues an output operation to an already active subfile record, an error message will be returned to your program. You may observe this condition by making the WRITE operation in the "Clear subfile" section of the FM01BL subroutine inactive by converting it to a comment.
If you do not specify a field with the SFLRCDNBR keyword, the operating system will display the first page of the subfile by default. You can create this error condition by converting the lines of code that define and reference field SFLPOS in the display file and program into comments. You will also have to define SFLRN1 since it is defined *LIKE SFLPOS:
*LIKE DEFN SFLPOS SFLRN1 MOVE *ZEROS SFLRN1 40
Now when you page forward, the program will add a page of records, but will always display the first page again. This is a sure way to lose favor with a user who is trying to get to the tenth page of a transaction file.
Some errors do not produce messages because they are system utilization errors. They can affect system performance and thus every user on the system. Our master file inquiry example assumes a relatively large file, in excess of 5000 records. If we were to use the first pseudocode algorithm to load and display the subfile, the user would wait several minutes for the program to read until end-of-file. The system would be burdened with storing the subfile records. The memory allocated to the program would be excessive, and some blocks of memory would be swapped to auxiliary storage. To avoid that condition, we only load one subfile page at a time. Since we provide a search value for database file positioning, it is likely that one or two pages of subfile records will be enough to locate any vendor.
Summary and Challenge
A subfile program is arguably the best way to provide for multi-record file inquiry on the System/38 and AS/400. In this article, our goal has been to cover the fundamentals of subfile programming. We have discussed the important subfile keywords used in a display file, and have related them to a sample program. The program uses an algorithm which is simple, but at the same time uses system resources effectively. The modular design of the program facilitates modification and enhancement.
Your challenge is to build an inquiry program for one of the master files in use at your shop. More advanced programmers are challenged to develop a search program. You should provide a means of vendor selection, and return the vendor number to the calling program as a parameter.
In the second article in this series we plan to build upon the foundation laid this month. We will discuss subfile entry, subfile error handling, and read-changed-records processing. We will present a transaction entry program which uses the same modular design as this month's program.
Happy rolling.
Special thanks to Hal Scherer, Team Leader, IBM Applications Systems Division Laboratory, Atlanta, for his ideas on modular program design.
Subfile Fundamentals, Part One
Figure 1 One page of a subfile display
------------------------------------------------------------------------------- Figure 1: One Page of a Subfile Display ------------------------------------------------------------------------------- C = Change, D = Delete ___Babka Publishing Company Dubuque, IA ___Baby Grand Corp. Las Vegas, NV ___Baby Needs Inc. Burlington, NC ___Baby Super Store Greenville, SC ___Baby Togs Inc. New York, NY ___Bacar Incorporated San Jose, CA ___Bacardi Imports Miami, FL ___Baccarat Inc. New York, NY ___Bachelor Beverage Bend, OR ___Bachmann & Associates Costa Mesa, CA F3 = Exit F5 = Address Search F9 = Add Mode -------------------------------------------------------------------------------
Subfile Fundamentals, Part One
Figure 2A Pseudocode for simple inquiry program
Figure 2a: Pseudocode for Simple Inquiry Program (1) Clear the subfile Reset subfile RRN to zero Reset SFLDSP indicator (2) Position the database file While not EOF Read the database file If not EOF Move data fields as required Increment subfile RRN Write subfile record EndIf EndWhile If subfile RRN > 0 Set SFLDSP indicator Else Set error indicator EndIf Initialize SFLRCDNBR field (optional) (3) Write/read subfile control format
Subfile Fundamentals, Part One
Figure 2B Pseudocode for simple master file inquiry
Figure 2b: Pseudocode for Sample Master File Inquiry (1) Clear the subfile Reset subfile RRN to zero Reset SFLDSP indicator (2) Position the database file after last record read Do 16 times or until EOF Read the database file If not EOF Move data fields as required Increment subfile RRN Write subfile record Save key of last record read EndIf EndDo If subfile RRN > 0 Set SFLDSP indicator Else Set error indicator EndIf Move subfile RRN to SFLRCDNBR field (3) Write/read subfile control format
Subfile Fundamentals, Part One
Figure 3A Physical file VENDPF
A UNIQUE A R VENDOR TEXT('Vendor Master') A VVEND 5S 0 COLHDG('Vendor' 'Number') A VNAME 25A COLHDG('Vendor' 'Name') A VADR1 25A COLHDG('Address' 'Line 1') A VADR2 25A COLHDG('Address' 'Line 2') A VCITY 20A COLHDG('City') A VSTAC 2A COLHDG('State') A VZIPC 10A COLHDG('Zip' 'Code') A VPHON 11P 0 COLHDG('Telephone' 'Number') A K VVEND
Subfile Fundamentals, Part One
Figure 3B Logical file VENDLF
A R VENDOR PFILE(VENDPF) A K VNAME A K VVEND
Subfile Fundamentals, Part One
Figure 4 Display file for Vendor Master Inquiry
A* A* SFL001DF - VENDOR MASTER INQUIRY A* A DSPSIZ(24 80 *DS3) A R FM01HDR A 1 2DATE A EDTCDE(Y) A 1 12TIME A 1 32'Vendor Master Inquiry' A DSPATR(HI) A 1 74'SFL001' A R FM01SFL SFL A VNAME R O 6 5REFFLD(VNAME VENDPF) A VVEND R O 6 32REFFLD(VVEND VENDPF) A EDTCDE(Z) A VCITY R O 6 40REFFLD(VCITY VENDPF) A VSTAC R O 6 62REFFLD(VSTAC VENDPF) A VZIPC R O 6 68REFFLD(VZIPC VENDPF) A VADR1 R O 7 7REFFLD(VADR1 VENDPF) A VADR2 R O 7 36REFFLD(VADR2 VENDPF) A VPHON R O 7 64REFFLD(VPHON VENDPF) A EDTWRD(' - - - ') A R FM01CTL SFLCTL(FM01SFL) A CA03 A N90 ROLLUP(81 'Roll up') A BLINK A OVERLAY A SFLDROP(CF11) A 20 SFLDSP A N98 SFLDSPCTL A 98 SFLCLR A 90 SFLEND A SFLSIZ(0009) A SFLPAG(0008) A SFLPOS 4S 0H SFLRCDNBR A 3 2'Search for ...:' A SEARCH 25A B 3 19CHECK(LC) A 21 ERRMSG('No records found for search- A value.' 21) A 5 2' Vendor name Numb- A er City State Zip- A ' A DSPATR(HI) A R FM01CK A OVERLAY A 23 2'F3=Exit' A 23 14'F11=Fold'
Subfile Fundamentals, Part One
Figure 5 RPG program SFL001 - subfile inquiry
F* F* SFL001 - VENDOR MASTER INQUIRY F* F* JEY 06/25/90 Original version. F* F* FILES USED F* NAME DESCRIPTION F* VENDLF Vendor Master by Name, Number F* F* INDICATOR REFERENCE F* 01 Redisplay indicator F* 20 Display subfile F* 21 No records found for search value F* 81 Roll up F* 90 Record not found; loop control; subfile end F* 98 Clear subfile F* N98 Display subfile control format F* FSFL001DFCF E WORKSTN F SFLRN1KSFILE FM01SFL FVENDLF IF E K DISK C*----------------------------------------------------* C* Field definitions. C*----------------------------------------------------* C *LIKE DEFN VNAME ENDNAM C *LIKE DEFN VVEND ENDVEN C *LIKE DEFN SFLPOS SFLRN1 C*----------------------------------------------------* C* Key list definitions. C*----------------------------------------------------* C ENDKEY KLIST C KFLD ENDNAM C KFLD ENDVEN C*----------------------------------------------------* C* Main processing. C*----------------------------------------------------* C* Program initialization. C EXSR ZFIRST C* Screen processing loop. C NXTSCN DOUEQ*BLANKS -1- C* Screen selection CASE. C NXTSCN CASEQ'FM01' FM01 -2- C CAS ZEXIT C END -2- C END -1- C* Return to calling program. C MOVE '1' *INLR C RETRN C*----------------------------------------------------* C* Display and process screen FM01. C*----------------------------------------------------* C FM01 BEGSR C* Build screen FM01. C EXSR FM01BL C* Write Header and Command key formats. C WRITEFM01HDR C WRITEFM01CK C* Screen display loop. C MOVE '1' *IN01 C *IN01 DOWEQ'1' -1- C MOVE '0' *IN01 C* Execute subfile control format. C EXFMTFM01CTL C* Screen processing CASE. C *IN81 CASEQ'1' FM01RU -2- Roll up C *INKC CASEQ'1' FM0103 F3 C CAS FM0100 Enter C END -2- C END -1- C ENDSR C*----------------------------------------------------* C* Build screen FM01. C*----------------------------------------------------* C FM01BL BEGSR C* Clear subfile. C MOVE '1' *IN98 C WRITEFM01CTL C MOVE '0' *IN98 C* Reset subfile record number and subfile display indicator. C MOVE *ZEROS SFLRN1 C MOVE '0' *IN20 C ENDSR C*----------------------------------------------------* C* Roll up processing. C*----------------------------------------------------* C FM01RU BEGSR C* Continue with record after the last one read. C ENDKEY SETGTVENDOR C DO 16 -1- C READ VENDOR 90 C *IN90 IFEQ '0' -2- C* Write subfile record. C ADD 1 SFLRN1 C WRITEFM01SFL C* Save end key fields. C MOVE VNAME ENDNAM C MOVE VVEND ENDVEN C END -2- C N90 END -1- C* If no records were added to subfile, set error indicators. C SFLRN1 IFEQ *ZEROS -3- C MOVEA'01' *IN,20 C* Else, set indicator and subfile RRN to display subfile. C ELSE -3- C MOVE '1' *IN20 C MOVE SFLRN1 SFLPOS C END -3- C* Set redisplay indicator. C MOVE '1' *IN01 C ENDSR C*----------------------------------------------------* C* Enter key processing. C*----------------------------------------------------* C FM0100 BEGSR C* Rebuild subfile with new search value. C EXSR FM01BL C MOVE SEARCH ENDNAM C MOVE *LOVAL ENDVEN C EXSR FM01RU C ENDSR C*----------------------------------------------------* C* F3-Exit. C*----------------------------------------------------* C FM0103 BEGSR C* Exit the program. C MOVE 'EXIT' NXTSCN C ENDSR C*----------------------------------------------------* C* Program initialization subroutine. C*----------------------------------------------------* C ZFIRST BEGSR C* Set up next screen work field. C MOVE 'FM01' NXTSCN 4 C ENDSR C*----------------------------------------------------* C* Program exit subroutine. C*----------------------------------------------------* C ZEXIT BEGSR C* Clear next screen work field. C MOVE *BLANKS NXTSCN C ENDSR
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