On Tue, 3 Nov 2009 16:46:26 -0600, Chris Craddock wrote: > >Au contraire. The 100 character limit has been documented since the >beginning of time. An unknowably large number of programmers wrote an >unknowably large number of (arguably incorrect) batch job step programs that >functioned correctly ONLY because they were guaranteed never to get more >than 100 bytes of parameter data from the initiator. You can play verbal >semantic games all you want, but THAT *IS* A CONTRACT to the programmer. We >can all agree it was a bad idea and that wiser programmers might have >properly dealt with the interface even then, but so what? All of those bad >programs will, for better or worse, continue to run safely because the >behavior of the initiator is not going to change. > "from the initiator" is a major hedge. Any of those bad programs (at least with AC=0) can readily be invoked with a long parm by other means. If this "*IS* A CONTRACT" it has so many loopholes that I'd deem it fraudulent.
>> If it were only a case of new programs then I would agree that the >> existing format is obsolete. However, existing programs, including those >> from IBM, support the existing interface for parms longer than 100. >> <http://bama.ua.edu/archives/ibm-main.html> > >No Shmuel, that's where you have it precisely backwards. SOME existing >programs can/do correctly interpret the existing interface when called with >a longer parm string by a program other than the initiator. An unknowably >large number don't behave that way and giving a JCL programmer a means (even >accidentally) to pass longer parameter data to those existing programs >through the existing interface is just begging for trouble, which is why it >won't happen. > Can't we assume that Shumel implied the "SOME"? And existing interfaces (not "the interface"; stop trying to pretend there's only one) allow (at least some: those with AC=0) existing programs to be passed longer parameter data. For those programs, the putative hazard has existed as long as the assembler CALL interface. The universe hasn't ended as a consequence. If system integrity or data security is a concern, then all means of calling any program with a long parm must be proscribed. >Dressing the proposal up with a cheat-sheet approach where the initiator can >consult a secret decoder ring to decide whether the long parameter string is >allowed or not is (frankly) kinda nutty. It presents loads more mechanism >and complexity for the OS and creates a maintenance problem with no >guarantees of avoiding a 3AM collision with an otherwise valid program whose >interface needs have not yet been documented. > Agreed. But much simpler: o AC=0: long parm allowed, as it is now via those pesky alternate interfaces. o AC=1: long parm prohibited, even as now. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
