What was advertised was that a main program was just another subroutine. OS/360 did not advertise that the caller of a subroutine would always pass correct parameters.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Charles Mills <[email protected]> Sent: Friday, December 1, 2017 3:48 PM To: [email protected] Subject: Re: LONGPARM > Many programs depended on the documented restriction that JCL-supplied parms > could > not exceed 100 bytes. While this may not be *the* greatest design, it was > common. And in fairness, we were constrained in those days by limited memory, 4K base register issues and relatively slow instruction times. Why waste bytes, addressability and cycles just to make sure OS/360 was behaving as advertised? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tony Harminc Sent: Friday, December 1, 2017 12:07 PM To: [email protected] Subject: Re: LONGPARM On 30 November 2017 at 22:26, Paul Gilmartin < [email protected]> wrote: > > >You can *never* pass more than 100 bytes via PARM=. If you want a > >longer parameter, you *must* use PARMDD. > > > >The interface as seen by the program is the same in both cases: > >halfword length followed by data. > > What about the ATTACH, XCTL, LINK, and LOAD/CALL macros. Prior to the > innovation of the LONGPARM attribute it was the responsibility of > either the parent or child task (not clearly documented which?) to > verify PARM length. There is nothing in the nature of ATTACH, XCTL, LINK or LOAD/CALL that suggests the argument(s) must be of the form halfword length followed by data. And indeed it's very often the case that internal routines have R1 pointing at some quite different data structure. For that matter R1 doesn't have to be a valid pointer at all. Any checking/rejection at the system level that assumed this kind of argument would cause huge breakage all over the place. > Do these nowadays respect the NOLONGPARM setting? > Clearly not. They have no way of knowing what kind of data the called program is expecting. A defensively coded subroutine should *always* validate its arguments. > No argument. (Yeah, I know...) > It seems OS/360 developers were unaware of this. I don't know why you say that. I think we've been through this a zillion times on this list. Many programs depended on the documented restriction that JCL-supplied parms could not exceed 100 bytes. While this may not be *the* greatest design, it was common. There was no integrity exposure until facilities to pass in long parms to a job step program became ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
