Dan, > Does one *have* to use a Choice Program as well? Some of the archives on > the topic connect the two, although my mind is still in MMM (Monday Morning > Mode). Choice Programs and POPs are not directly related. You use them for different purposes. You may opt to use one or the other or both, depending on what you are trying to achieve. A choice program allows one to dynamically provide the text which appears on the right side for a keyword while multiple keywords are shown, and to dynamically control the choices displayed when F4 is pressed (or ? keyed) on a single keyword. A choice program never alters the value of a keyword value itself -- it simply provides a dynamic means of controlling the choices the user sees. Choice programs have been available since CPF days. OTOH, a POP can change the actual keyword values but generally will have one or more "key" parmameters (eg PARM ... KEYPARM(*YES) ... ). POPs got added back in V1R2 or so, because users complained they didn't like seeing *SAME on things like various CHGxxx commands. They wanted to see the existing value instead. You place KEYPARM(*YES) on one or more "key" parameters used to help the POP decide what values to provide for additional keywords. For example, with CHGJOBD, the keyword JOBD would be the key parm. When one or more key parms exist, they get prompted (alone) first before the POP gets called. Then the POP is supplied with the key value(s) and can override other parameters. In the case of CHGJOBD, once the POP knows which JOBD you wish to alter, it can supply current values for many keywords instead of the *SAME which is the actual default value. If no command keywords are coded with KEYPARM(*YES), then it is possible to still use a POP. However, the only thing the POP will know is the library and command name which is being prompted. It doesn't have direct access to any other keyword values which may have been supplied on the command. This can still be useful for stuff like dates though. >Would like to know how these elements need to be formatted. I would >like them to be displayed as mm/dd/yyyy and hh:mm:ss. The POP returns the keyword(s) to be modified as if part of the command string. If supplying more than one keyword, separate them by spaces just like on a command line. Because / and : are special characters, keyword values containing them must be enclosed in parentheses. So a POP might return something like this: ??DATE('mm/dd/yy') ??TIME('hh:mm:ss') as the contents of its second parameter. To build that up in RPG you may use something like: cmd = '??DATE(''' + %Date( value: *MDY) + ''') ??TIME(''' + %Time( value: *USA) + ''')' Note the use of 3 consecutive single quotes in some places, two of which convert to a single quote within the field value contents itself. I should note here that I prefer to use *CHAR fields for dates and times instead of a *DATE or *TIME type keyword. This allows my VCP and CPP to examine the contents and provide my own parsing of the value. This permits me to let the user key the value in a variety of formats or separators instead of conforming to the prompter's expectations for *DATE and *TIME keywords. What I do use both a POP and a choice program (well, and a VCP) for dates. The POP is used as above to supply an actual value as a default in lieu of the keyword's default coded as something like *TODAY. The VCP is used to validate their entry since I prefer *CHAR to *DATE and thus don't have the automatic date validation of the prompter. The choice program is used to show a calendar when one of my date parms is prompted. Doug PS - A common misconception is that a POP will supply a default value for a command. The truth is that a POP is only called when a command is prompted. If you run a command without prompting, the POP is never called and thus cannot supply values for any keywords. So don't make the command processing program reliant on always having an explicit value -- you still may want a default such as *SAME for CHGxxx type commands or something like *TODAY for a date keyword on other commands.
This mailing list archive is Copyright 1997-2013 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact