I'd like to cast a vote for JCL PARMs longer than 100 bytes, using the current scheme simply (?) by increasing the upper limit.
I agree with protecting APF authorised programs from inadvertent parameter "overrun". I don't think non-APF authorised programs need this protection, although I would expect IBM to check its IEB/IEH utilities, and other common programs like service aids for problems in this area. Assuming a program is expecting a parm length no more than 50, code like LH R2,0(,R1) CH R2,=H'50' BH PARMLONG will not trap a 40,000 byte parm, but the JCL "deck" size may be a bit of a giveaway, so no big deal IMHO. I think computers can count data bytes better than humans, so I liked someone's idea (much earlier in this thread) of a JCL info message reporting the PARM length for each step which has one. This may provide a very handy diagnostic for long PARMs. Further, I think this message should be issued no matter what the PARM length (ie. even for very short PARMs) whenever the system has long PARMs enabled, as an obvious flag to all that long PARMs are currently allowed by the system. (Dispense with the DISPLAY command, perhaps?) Cheers, Greg P. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
