Q: Can someone please explain the difference between the CF(xx) and the CA(xx) indicators in a subfile? Also, how does the INxx indicator relate to the INKx indicator in RPG? For example, how does *IN03 relate to *INKC? I see programs where the programmer checks *IN03 after EXFMT. How do these indicators get turned on and off? Once an indicator is turned on via a function key being pressed (*IN06, for instance), does the operating system turn it off? If so, when does it turn it off?
A: Subfiles aren't at issue here; the CF and CA keywords are used to enable function keys. CF01 and CA01 both enable the F1 key on your keyboard. The difference is that a CF (command function) key updates the fields in your program, while a CA (command attention) key does not.
It's a little more involved than that, however. A CA key also bypasses any field editing. For example, if you enter a bad value into a field that has the VALUES keyword specified in the DDS and then press a CF key, you will get an error, and the screen will not be returned to the program because the field doesn't pass validation. If, on the other hand, you hit a CA key, the editing is bypassed, and the CA key is returned to the program (although the fields are not). The best use for CA keys is keys that exit a screen without updating data--typically, CA03 or CA12 in iSeries applications.
Okay, that's the difference between CA and CF keys. Now, on to indicators.
If you define CF01 or CA01 in your DDS, and the user hits the F1 key, then the *INKA indicator is turned on in your program. You can, however, specify an additional indicator to be used, by using a syntax such as CF01(01). With this keyword, F1 will turn on both *INKA and *IN01. There is no hard and fast relationship; if you specified CF01(22), F1 would turn on both *INKA an *IN22.
The indicators (*INKA through *INKY) are turned either off or on with each READ or EXFMT, depending on which function key the user pressed. Thus, there should never be more than one *INKx indicator on, and often none are on (if the user hits Enter or if one of the non-command keys is enabled, such as PageUp or Help).
Finally, any indicators specified in the DDS in the syntax CF01(nn) are set based on the setting of the associated command key.
Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc., which offers PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has been working in the field since the 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe is also the author of E-Deployment: The Fastest Path to the Web and Eclipse: Step by Step, as well as "Weaving WebSphere," a monthly column in MC Mag Online. You can reach him at




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