Reputation: 63
So, I've looking to build an iSeries / IBMi command, which has the option of additional codes (these are essentially transaction codes), it should allow you to specify...but I'd like to default the first 3 out of a maximum of 10.
My source
PARM KWD(FROMDATE) TYPE(*CHAR) LEN(10) +
PROMPT('From YYYY-MM-DD')
PARM KWD(TODATE) TYPE(*CHAR) LEN(10) PROMPT('To +
YYYY-MM-DD')
PARM KWD(TXN) TYPE(*CHAR) LEN(1) RSTD(*YES) +
DFT(Y) VALUES(Y N) PROMPT('Specify TXN +
Codes Y or N')
PARM KWD(TXNLIST) TYPE(L2) PMTCTL(CHOOSETXN) +
PROMPT('TXN Code List')
L2: ELEM TYPE(*CHAR) LEN(5) MIN(0) MAX(10)
CHOOSETXN: PMTCTL CTL(TXN) COND((*EQ Y))
shows the command,
Type choices, press Enter.
From YYYY-MM-DD . . . . . . . . __________ Character value
To YYYY-MM-DD . . . . . . . . . __________ Character value
Specify TXN Codes Y or N . . . . Y Y, N
TXN Code List:
_____ Character value
+ for more values _____ ```
but I'd like the TXN Code List to be pre-populated??
E.g. pre-populate first three with "AA123", "BB124" & "ZZ999"
Upvotes: 2
Views: 867
Reputation: 63
OK...so it looks like a SUBTREE will suffice...
CMD PROMPT('GENERATE TXNS')
PARM KWD(FROMDATE) TYPE(*CHAR) LEN(10) +
PROMPT('FROM YYYY-MM-DD')
PARM KWD(TODATE) TYPE(*CHAR) LEN(10) +
PROMPT('TO YYYY-MM-DD')
PARM KWD(SUBTREE) TYPE(*CHAR) LEN(1) RSTD(*YES) +
DFT(Y) VALUES(Y N) PROMPT('SPECIFY')
PARM KWD(TXNLIST) TYPE(TXNVALS) +
PMTCTL(SUBTREEY) PROMPT('TXN CODES')
TXNVALS: ELEM TYPE(*CHAR) LEN(5) DFT(AA123)
ELEM TYPE(*CHAR) LEN(5) DFT(BB124)
ELEM TYPE(*CHAR) LEN(5) DFT(ZZ999)
ELEM TYPE(*CHAR) LEN(5) DFT('')
ELEM TYPE(*CHAR) LEN(5) DFT('')
ELEM TYPE(*CHAR) LEN(5) DFT('')
ELEM TYPE(*CHAR) LEN(5) DFT('')
ELEM TYPE(*CHAR) LEN(5) DFT('')
ELEM TYPE(*CHAR) LEN(5) DFT('')
ELEM TYPE(*CHAR) LEN(5) DFT('')
SUBTREEY: PMTCTL CTL(SUBTREE) COND((*EQ Y))
Which looks like this...although I still need to test the CL parameters...
GENERATE TXNS (TESTCMD)
Type choices, press Enter.
FROM YYYY-MM-DD . . . . . . . . FROMDATE
TO YYYY-MM-DD . . . . . . . . . TODATE
SPECIFY . . . . . . . . . . . . SUBTREE Y
TXN CODES: TXNLIST
AA123
BB124
ZZ999
_____
_____
_____
_____
_____
_____
_____
Upvotes: 3
Reputation: 23823
Unfortunately, the DFT
keyword for a parameter definition only supports a single value.
My first thought was perhaps you could take advantage of prompt override program which:
allows current values rather than defaults to be displayed when a command is prompted
The way that would work would be to have a special value *DFT
or something defined as default. If a user prompted the command, then they could see the actual values. But looks you'd need to specify PMTCTL(*PMTRQS)
since it's a list parm instead of a single value; which means the user would also have to hit F10=Additional parameters.
Upvotes: 2
Reputation: 1324
One way to populate those is to do so in a CL program that calls this command. You can fill out the parameters using local variables where you set your default values.
DCL VAR(&TX1) TYPE(*CHAR) LEN(5)
DCL VAR(&TX2) TYPE(*CHAR) LEN(5)
DCL VAR(&TX3) TYPE(*CHAR) LEN(5)
CHGVAR VAR(&TX1) VALUE('AA123')
CHGVAR VAR(&TX2) VALUE('BB124')
CHGVAR VAR(&TX3) VALUE('ZZ999')
MYCMD TXN(Y) TXNLIST(&TX1 &TX2 &TX3)
If you wanted, you could additionally use selective prompting of your command, for instance, if you have one type of user whom you want to allow input of the date selection fields, but want to use only the default transaction codes, you could call your command as
MYCMD ??FROMDATE(*N) ??TODATE(*N) ?*TXN(Y) ?*TXNLIST(&TX1 &TX2 &TX3)
One might not want the extra layer using of another program to accomplish a task, but it could also be viewed as separating the concerns into their proper place. I like to think of a CMD object as a controlled way to define parameters for a program, similar conceptually to a prototype. This ensures that I call my RPG (or whatever) program in a consistent way and allows me not worry as much about corrupt junk coming in via the parameters. I would say one should let the CMD object be that traffic cop to ensure predictable combinations of valid parameters and let any specific defaults, which I picture as more likely to be changeable over time and situation be set in a CL program.
Some of this choice may be weighted by how users get to your command. I work in a system where most users call programs from a custom menu and it is easy to set a CL program in the chain. If your use case was for programmers or system operators to call this directly off of the command line, then you might think that it is easier to call the CMD object with an F4 prompt than to type CALL MYCMDTX
to call the CL, especially if you end up needing parameters there also.
Upvotes: 2