Re: soft coding parameters

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.