On Tue, Nov 3, 2009 at 1:36 PM, Shmuel Metz (Seymour J.) < shmuel+ibm-m...@patriot.net <shmuel%2bibm-m...@patriot.net>> wrote:
> In <6fh0f55c4lt4scbntma0r9udums736r...@4ax.com>, on 11/03/2009 > at 05:06 PM, Binyamin Dissen <bdis...@dissensoftware.com> said: > > >The API is defined as 100 byte maximum > > There is no such formal API. The limitations of the R/I and C/I were just > that, limitations. They were never a contract to the programmer. 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. > >New programs wishing to use a > >larger plist can be coded to use a new way to get to the data. > > 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. 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. -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- 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
