Perhaps it is a prejudice of where I sit in 2017 but I just don't see 64- vs 31/32-bit the way I see 31/32-bit versus 24. For example, IBM has had to go through some convolutions with system tables. The ECVT exists because IBM did not want to consume more 24-bit address space for the new fields (and did not want to break compatibility by moving the CVT above the line). Perhaps it is my limited vision, but I just don't see IBM running out of space below the bar for system tables.
Yes, customer COBOL and PL/I programmers are shielded from xSAM/31-bit concerns, but not customer assembler programmers. Witness the questions here from time to time. Frankly, the mistake IMHO was putting the DCB in the application. (Granted, I am sure storage concerns played a part in the design.) Had OPEN returned a magic token (as fopen() does in UNIX and Windows) rather than operating on a local control block, and APIs been provided for returning or manipulating the LRECL, the RECFM and so forth, the 24-bit xSAM problem would not exist. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Peter Hunkeler Sent: Monday, December 4, 2017 11:56 PM To: [email protected] Subject: AW: Re: Access registers >I believe someone (Harlan Mills? Fred Brooks?) said that he felt the only (or most significant?) *error* in the System 360 design was the 24- rather than 31- or 32-bit addressing. > >Anyone who has wrestled with legacy control blocks in the modern era would probably agree. Hmmm, if all those address fields in those nasty legacy control blocks were 32 bit fields, what would you say about the fact that they cannot hold modern era's 64bit pointers? Other platforms have had and have similar problems that resulted from decision that had to be made at some time. The *big* difference, IMHO, between IBM Z (or whatever it was and will be called) decided in favour of compatibilty. Other platforms decided in favour of dropping legacy requesting rewriting at least parts of the code every few years. I'm with the IBM Z approach. The limitations imposed concern only few (ISVs); Cobol, PL/I, etc programmers mostly don't have to care.
