The exact possibilities for the content of a PARM in a JCL deck depend on an interaction between "JCL" and the data the parm represents, (as David W Noon was keen to impress in the other thread on this).
What happens for PARM-in-JCL need not happen for PARM-in-PARMDD. PARMDD did not exist previously, you have to change the JCL significantly to use it, PARMDD data contains no elements of JCL, nothing relating to JCL directly (unless you count the symbol-substitution and && compression) and "does some other stuff", stripping what it (it being the PARMDD processing) thinks is a line number. Taking your original example and putting it in PARMDD would not work, because the program using the PARM data would not understand the extra information. Taking Charles' example and removing the comments and putting it in PARMDD would not work, because some of the PARM formatting in that example is to allow for the presence of the comments (those apostrophes). Taking any PARM which has required extra formatting because the data of the PARM conflicted with JCL's understanding of how a line is formed and putting it unchanged into PARMDD would not work, because those extra bits of formatting for the JCL are still there, and now part of the data, which the program using the PARM data will not understand. PARM is data. You can "embed" a comment in the JCL, but it is embedded in the JCL, not the data (in your example the commas have a dual role, they are data, and the JCL-processor sees them as JCL). PARM is data. Sometimes the data requires encapsulation so that the JCL-processor understands. PARMDD is data. There is no requirement or capability for de-encapsulating JCL that in an original PARM existed only to enforce a distinction between the data and the JCL. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
