Re: Prompt Override Program example using date & time?

[Douglas Handy <dhandy@xxxxxxxxx>]

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.