Since the early days of the CPF operating system on the System/38, We've been bedeviled by specifying variables for list parameters in CL programs. For every other parameter on the system, if you need to specify a variable you're good to go, but there has never been a good way to specify a variable with list parameters. If you specify one list element you're OK, but that's rarely what is needed. Often times one needs to specify multiple list elements and you can never be sure how many will be needed at execution time. The current design of the command processing environment makes this difficult.
There has always been a potential security problem using API's like QCMDEXC (see “work-around” below). It can crop up when the program adopts the authority of a security officer profile like QSECOFR. If not done properly there is potential for a rogue programmer to debug the program and change the command it executes to some other command (like one that will change the password of a secured profile). Also, if the command you're executing is SBMJOB, then the program that is called in the CMD parameter won't appear in that submitting program's DSPPGMREF output.
The standard work-around for this problem has always been to create a CL command in a variable and then execute it with a command execution API like QCMDEXC, but there are inherent problems (see “impact” above).
The solution combines with requirements #212 (Arrays in CL) and #215 (Qualified Data Structures in CL), and it proposes to change the command environment to allow arrays and data structure arrays to be specified in list parameters. This will eliminate the “impact” issues by giving the CL command environment a discrete set of data elements. Full details and illustrations can be found at this URL on the System i News iDigress blog: http://www.systeminetwork.com/blog/idigress-23/rpg-programming/solving-problem-list-parameters-variables-cl-699271