Command prompting control is not executing when no value is entered for a required parameter. Meaning, if a user prompts a command that has a required parameter but then simply presses ENTER instead of filling in the required parameter value, no error message is displayed but all prompting control is also ignored and all parameters are displayed -- including parameters that are normally mutually exclusive of each other.
I opened a PMR for this situation and was told that it is "working as designed" because it is documented that when a required parameter is not supplied then command prompting will display all parameters. Well, I have to tell you that the design is flawed.
It is never "OK" to go ahead and display mutually exclusive parameters. The reason is that it both presents an erroneous (and confusing) display to the user, but it also allows the user to enter data where they shouldn't with no way to programmatically get rid of that data during prompting.
Meaning, once a value is entered into the required field and prompt control *does* execute, prompt control is unable to remove the mutually exclusive parameters from the display because they have values specified in them.
Better, in this case (required fields not filled in), is to not display *any* parameters that have PMTCTL specified. Further, what value is it to allow a PMTCTLPGM to be specified and then NOT call that program so that it can control prompting as it is supposed to be able to do?
In short, prompt control is broken because it does not give the programmer the promised control over command prompting as implied.
There are three ways you can address this issue.
1. Simply change command prompting behavior to not display parameters with PMTCTL specified if required parameters are not supplied.
2. Simply change command prompting behavior to always execute prompt control even if required parameters are not supplied.
3. Add new PMTCTLOVR parameter to the CMD header with options of *NONE (default, for original behavior), *SKIP (don't display parameters with PMTCTL if required fields are not supplied), and *ALWAYS (execute PMTCTL even if required fields are not supplied) to make all three behaviors possible.
Use Case: The following two source members (slightly modified from the example given in the IBM manual) demonstrate the problem.
CMDTEST: CMD PROMPT('Test Prompting Control')
PARM KWD(OBJ) TYPE(Q1) MIN(1) PMTCTLPGM(CMDTESTP) +
PROMPT('Object name')
Q1: QUAL TYPE(*NAME) LEN(10)
QUAL TYPE(*NAME) LEN(10) DFT(*LIBL) +
SPCVAL((*LIBL)) PROMPT('Library')
PARM KWD(CMDPARM) TYPE(*CHAR) LEN(10) PMTCTL(CMD) +
PROMPT('Command parm')
PARM KWD(PGMPARM) TYPE(*CHAR) LEN(10) PMTCTL(PGM) +
PROMPT('Program parm')
PARM KWD(FILEPARM) TYPE(*CHAR) LEN(10) +
PMTCTL(FILE) PROMPT('File parm')
PARM KWD(OTHERPARM) TYPE(*CHAR) LEN(10) +
PMTCTL(OTHER) PROMPT('Other parm')
CMD: PMTCTL CTL(OBJ) COND((*EQ '*CMD')) NBRTRUE(*GT 0)
PGM: PMTCTL CTL(OBJ) COND((*EQ '*PGM')) NBRTRUE(*GT 0)
FILE: PMTCTL CTL(OBJ) COND((*EQ '*FILE')) NBRTRUE(*GT 0)
OTHER: PMTCTL CTL(OBJ) COND((*EQ '*')) NBRTRUE(*GT 0)
CMDTESTP: PGM PARM(&CMD &PARMVAL &RTNVAL)
DCL VAR(&CMD) TYPE(*CHAR) LEN(20)
DCL VAR(&PARMVAL) TYPE(*CHAR) LEN(20)
DCL VAR(&RTNVAL) TYPE(*CHAR) LEN(32)
DCL VAR(&OBJNAM) TYPE(*CHAR) LEN(10)
DCL VAR(&OBJLIB) TYPE(*CHAR) LEN(10)
CHGVAR VAR(&OBJNAM) VALUE(%SST(&PARMVAL 1 10))
CHGVAR VAR(&OBJLIB) VALUE(%SST(&PARMVAL 11 10))
CHGVAR VAR(&RTNVAL) VALUE('*CMD')
CHKOBJ OBJ(&OBJLIB/&OBJNAM) OBJTYPE(&RTNVAL)
MONMSG MSGID(CPF9801) EXEC(GOTO PGM)
GOTO CMDLBL(EXIT)
PGM: CHGVAR VAR(&RTNVAL) VALUE('*PGM')
CHKOBJ OBJ(&OBJLIB/&OBJNAM) OBJTYPE(&RTNVAL)
MONMSG MSGID(CPF9801) EXEC(GOTO FILE)
GOTO CMDLBL(EXIT)
FILE: CHGVAR VAR(&RTNVAL) VALUE('*FILE')
CHKOBJ OBJ(&OBJLIB/&OBJNAM) OBJTYPE(&RTNVAL)
MONMSG MSGID(CPF9801) EXEC(GOTO OTHER)
GOTO CMDLBL(EXIT)
OTHER: CHGVAR VAR(&RTNVAL) VALUE('*')
EXIT: ENDPGM
1. To define some of these parameters to be mutually exclusive, you can add Dependent Definition (dep) for those parameters.
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/cl/dep.htm
2. Prompter is one of the interactive ways to run a command, without dep definition, mutually exclusive parameters still could be a specified value in command line.
3. The value specified for the controlling parameter is in error, that means the value is not valid according to command definition. The prompter stops calling prompt control program because we commit that all the parameter values passed to prompter controlling program are VALID, and in prompter control program, there is no need to check the input value again. With out that, unpredictable events will happen in prompt control program.
4. Yes, we agree that it is better to display an error message before showing all the controlled parameters in this case: "if a user prompts a command that has a required parameter but then simply presses ENTER instead of filling in the required parameter value, no error message is displayed but all prompting control is also ignored and all parameters are displayed"
Thank you for your suggestions.
The CAAC has reviewed this requirement and recommends that IBM view this as a high priority requirement that is important to be addressed. The behavior should always result in a positive action, and not a loop.
Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.
For more information about CAAC, see www.common.org/caac
For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/
Nancy Uthke-Schmucki - CAAC Program Manager