<snip> The buglet that needs fixing is // set A='&USER' // EXEC PGM,PARM='Z &A Y' the parameter passed to the program is 'Z' I would expect either 'Z Y' or 'Z &USER Y ' </snip>
In general, that is not the behavior for started task processing. This proc produces a 5-character parameter of "Z U Y": //MYPROC PROC USER=U // SET A=&USER //MYPROC EXEC PGM=NOTVALID,PARM='Z &A Y' The same proc, changing the SET to // SET A='&USER' fails with IEFC657I as has been discussed. And yes, that is unfriendly. The same proc, changing the SET to // SET B=&USER // SET A='&USER' to overcome the IEFC657I situation, produces a 9-character parameter of 'Z &USER Y' <snip> //IHS EXEC PGM=BPXBATCH,REGION=0M,PARMDD=PARMDD //PARMDD DD *,SYMBOLS=EXECSYS SH /u/mqweb3/conf/ccc.sh aa &A2 x &AV &T1. y &AV. z /* //STDOUT DD SYSOUT=H //STDERR DD SYSOUT=H prints out the parameters aa </snip> Maybe BPXBATCH and SH do not process the parameter string as you are thinking/expecting they do. I have no idea what the BPXBATCH rule is for passing parameter data supplied on a SH statement. I think you have subsequently concluded that your problem is not with how the parameter string itself is presented to the BPXBATCH program, but further downstream. A bug in BPXBATCH processing (and/or a doc problem), is worth reporting. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
