How many of the programs designed to run in batch are coded to cope with longer than 100 byte parms? Not too many probably. Programs need to verify data they receive from "untrusted sources". PARM is untrusted because it is entered "manually". How many programs have code to verify the PARM does not exceed 100 bytes. None, probably, because it is an architectural limit; JCL inhibits longer than 100 byte PARMs, no need to verify again in the program.
Imagine some typo in the JCL makes the PARM longer than 100, say 102 bytes. Imagine the program moves the PARM to some internal variable. Imagine the variable next to this variable is a halfword constant used in some calculation. Imagine the program modifies data in a data base applying the calculation to some data base fields. The program won't fail; it will happily run with an arbitrary value in the formula. Dangerous incompatibility, isn't it? I'd strongly suggest the binder attribute is declared an absolute must to allow passing longer than 100 byte PARMS to the program. APF or not doesn't matter. Instead of making sure all APF programs can cope with longer than 100 byte PARMs, I suggest we make sure the (few) utilities that should support longer PARMs do and have the binder bit set. There is *no* need for customers to re-bind all programs; most of them neither support nor need longer PARMs. The few that might can be re-bound if the customer decides to do so. The benefit: No need for a system wide option, no need for a system command, cheaper to implement, and most importantly, no unnecessary incompatibility. Just my 2 cents, of course. Peter Hunkeler Senior IT Specialist, IBM zSeries Technical Sales Support, Switzerland ---------------------------------------------------------------------- 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
