Then, in "Page II--The Midrange Manager," I include QuickReviews of two very important tools for any AS/400 shop, the highly reliable MochaSoft Telnet-based 5250 emulator and the Work with Database File (WRKDBF) command. Mocha's 5250 emulator is fast becoming the emulator of choice for AS/400 shops and consultants who want to avoid the "issues" that occur from installing Client Access on their PCs. WRKDBF is currently a freeware utility that is downloadable from its own Web site. It is an AS/400 tool that displays any database file and allows editing of that database file. In addition, it supports the surprising ability to undelete previously deleted records!
Indicator-Free Function Keys
Everyone uses DDS for display files. Most display file formats have function keys enabled to cancel an action, back up a process, do a search, or perform some other task. We all know that, in DDS, function keys can be either Command Function keys, identified by the CFxx keywords, or Command Attention keys, identified by the CAxx keywords.
The only difference between CF keys and CA keys is that CF keys return data to the program from the display file and perform any DDS-based error checking. CA keys do not return data to the program and therefore avoid any DDS-based error checking. One common use for CA keys is the F5=Refresh function. F5 is usually enabled by specifying a CA05 keyword in the DDS. This allows the end-user to press F5 and have an undo-style function performed without any significant programming.
As RPG programming has evolved, the use of indicators has fast become taboo. However, using indicators in display files has always been problematic, particularly when specifying function keys.
"Specify a response indicator," as it is called, causes the system to automatically set on an associated indicator when the function key is pressed. This normal practice easily allows the RPG programmer to test which function key was pressed. It is a practice I hope to make extinct.
If you' re a long-time RPG programmer--and I mean pre-OS/400 and pre-CPF (System/38)--you may remember something about the Attention Identification Byte. This byte is a one-position field in the Information Data Structure for WORKSTN device files (WSDS) and is automatically updated when the end-user presses a function key.
The Attention Identification Byte is stored in position 369 of the WSDS and can be accessed by including code in your program that is similar to the code in Figure 1.
|
Figure 1: Attention Identification Byte in the WSDS
The WSDS data structure on line 3 contains two subfields: Fkey and Fkey_Alt. You need to use only one of these fields, but I wanted to illustrate the alternate syntax for specifying the subfield. Fkey (line 4) uses the traditional From/To column notation. Fkey_Alt (line 5), on the other hand, is the same as Fkey but uses the Overlay keyword to identify the location in the WSDS where the field appears. Either is acceptable in this situation. Regardless of style, I would use the name Fkey as the field name used in your code.
Line 6 illustrates how to include the source member I feature later in this article in Figure 4.
Traditionally, to specify the command keys in your DDS, you would use response indicators, similar to Figure 2.
|
Figure 2: Traditional DDS with Response Indicators
This traditional DDS style can be used with the Attention Identification Byte, so you don't have to change your existing DDS source code to take advantage of this technique. However, you no longer need to specify response indicators if you intend to use only the Attention Identification Byte technique. So that same code from Figure 2, rewritten to take advantage of the Attention Identification Byte technique, would appear as in Figure 3.
|
Figure 3: DDS Without Response Indicators
So, how do you use this technique? Well, you first need to create a separate source member that you subsequently /COPY into your applications. This source member should contain named constants, using symbolic names that represent the scan code for the various function keys. What scan code you use depends on whether your executable is running on an EBCDIC machine, like the AS/400, or an ASCII machine, such as Windows or a flavor of UNIX. Since 99.9999% of all RPG today is EBCDIC, I've included the /COPY for you in Figure 4.
|
Figure 4: Source Member FKEYS; Named Constants for Function Keys
Use /COPY to insert the source member into any RPG IV source code that uses this Attention Identification Byte technique. Figure 5 shows an example of how to use the Fkey subfield and the named constants.
|
Figure 5: Example Use of Function Key Scan Codes in RPG IV
I call this technique Function Key Scan Codes, and I use it exclusively in my code. I no longer use response indicators and have always thoroughly disliked the use of the RPG II *INKx indicators.
In your own code, I suggest that you try to use this technique as your shop standard for new code and work it into older code as time permits.
What About the Indicator Data Structure (INDDS)?
The INDDS is different technology than the technology that uses the Attention Identification Byte. IBM Canada put INDDS into RPG IV because IBM U.S. (Rochester) had not enhanced DDS to allow the programmer to avoid the use of indicators.
The INDDS allows you to automatically map the indicators from a workstation display file into a data structure that is 99 positions in length. Each position in that data structure corresponds to one of RPG's numeric indicators. For example, position 32 of the INDDS maps to indicator 32 used by the corresponding workstation file. So if indicator 32 is used to condition the DSPATR(HI PC) keyword in your DDS, you would use position 32 of the INDDS to avoid referring to *IN32 in your RPG code. Instead, you would assign a field name, such as whose data type is "N" (Named Indicator), to position 32 of the INDDS data structure.
Take care when you use this technique. Though it's very useful, it does eliminate your ability to manipulate the indicators used in the workstation file through their traditional names. That is, using the INDDS replaces access to the indicators used in your display file DDS. If, for example, you use indicator 32 in a display file and use the INDDS in your program, the state of indicator 32 in the program becomes irrelevant to the display file. You can set it off or on, but the keywords or fields in the DDS conditioned by indicator 32 will not be impacted. Only changes to position 32 of the INDDS will affect indicator 32 as used by the DDS. This means that you don' t have to worry about which indicators are used and for what purpose. And that's a good thing.
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