Once again I suspect we are focusing on errors which are probably unlikely.

Most programs don't accept long parameters from PARM= today, nowhere near the 100 char limit. The most common exception is compiler/binder options.

I see in the HLASM manual that it already accepts parms up to 32766 bytes; its parms can be specified in several different ways, not just PARM=, but I am willing to bet that it will accept a JCL parm up to 32766 today if JCL were modified to pass it. I would not be surprised if this were also true in other current IBM compilers.

So for a problem to occur, it would have to be a program which:
1) accepts complicated or long parameters, such that a programmer might accidentally code a PARM= over 100 bytes
2) the program does not validate the max length of the parms it accepts (trusting to JCL to enforce it) - HA and HA HA! Since I can code a LINK to any program and pass it a simulated PARM area over 100 bytes today, any program which doesn't accept it or fail it with a meaningful msg is poorly coded.


I am sure this problem will occur somewhere, but I can't see a rash of such errors on the day large PARM is enabled. I would not lose any sleep worrying abou it.

Even then I would think it wouldn't take a competent sysprog long to notice the very long parm and deduce the cause of the problem

--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

----------------------------------------------------------------------
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

Reply via email to