On 24 Mar 2013 17:13, Booth Martin wrote:
<<SNIP>>
I believe there is a simpler answer that so far hasn't been put
forward. Probably it hasn't been put forward because it isn't
what I believe it to be. But hey, never stopped me yet, eh?
Is what is needed here a "prompt override program"?
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rbam6/pop.htm
"Key parameters and prompt override programs
The prompt override program allows current values rather than defaults
to be displayed when a command is prompted. Key parameters are
parameters, such as the name of an object, that uniquely identify the
object. ..."
While there are possible ways to shoehorn a POP into the scenario of
the OP, I do not see that as a worthwhile endeavor for two reasons.
First, adding a POP to a vendor-supplied command, generally is not a
good idea; mostly because the vendor may have one already defined for
the command or might add one eventually. Second, there is little to be
gained directly by making use of a POP, because the data being made
available via a POP would come from some separate previously populated
/soft/ location, just as would be the case when implemented without
using a POP. So a new user-created command MYMQAXAMC with a key
parameter that defines the defaulted parameter specifications for the
parameters of the MQAXAMC command could be one way to effect that, but
hardly /simple/ in my opinion, esp. if creating a new version of the
command with the new key parameter(s); e.g. the request to ?MYMQAXAMC
KEYPARM(*START PROGRAM_NAME) could effectively populate all of the
desirable defaults for the ?MQAXAMC FUNCTION(*START) when that request
is to be invoked from program PROGRAM_NAME. But any program could
effect establishing those defaults from the soft location just as
easily, without ever having a new command or a POP involved.
FWiW: The primary use of a POP is to replace the value *SAME for a
CHGxxx command, when a /key parameter/ defines whence the values that
correspond to *SAME should be retrieved. Thus for a command like
CHGUSRPRF where the USRPRF() parameter is the key parameter, when that
command is prompted without a User Profile named on that parameter,
[typically for such a command all of] the other parameters will have a
value of *SAME. However when that same command is prompted with a User
Profile named on that parameter, and that *USRPRF object exists, the POP
can retrieve all of the /current values/ for the other parameters
defaulting to *SAME, replacing each special value of *SAME with its
corresponding /current value/ retrieved from the user profile object.
Thus the requester of the prompted CHGUSRPRF command can /see/ the
current value of those other parameters, rather than seeing the special
value *SAME.
An example of where a POP probably should have existed, on a command
other than a CHGxxx, is the RUNQRY command for its *RUNOPT values which
intends to imply the equivalent value\option from the *QRYDFN object;
with the key parameter being the QRY() parameter, used to identify the
library and name of the specific query definition object to run. A
non-CHGxxx command which always did have a POP, is PRTDOC which replaces
the *SAME values which [like the *RUNOPT] intend to imply what
value\option is stored in the *DOC object; with the key parameters being
the combined FLR() and DOC() used to locate the specific *DOC object to
print.
midrange.com
