On Fri, 4 Jul 2014 11:18:12 -0400, John Gilmore wrote: > >..., but z/OS is still full of gaps in >the facilities it makes available for work above the bar, through many >of which one could drive the proverbial tank. > Such as executing code above the bar. But I've wondered before, and seen no comment, whether 31-bit address space constraint is onerous, particularly for LPA. I.e. how often is address space constraint a consideration when deciding what should go in LPA for performance reasons otherwise?
>When, for example, the HLASM does not yet support doubleword >set-symbol arithmetic . . . > This has been discussed on ASSEMBLER-LIST; one of the infrequent topics on which you and I agree. At that time an IBM employe defended HLASM; I agree with half his technical arguments. o 64-bit expressions would impel incompatible changes in ASMADATA format. Yes; and I'd be not much satisfied with a compatibliity option. o There would be quiet changes in the results of experession evaluation, possibly incompatible with existing art. Here, I disagree. HLASM responsibly reports as errors overflows in expression evaluation, so any (adverse) effect on assembler behavior would be limited to programers accustomed to ignoring those errors. I don't sympathize with them. (But I do know one instance in base-displacement resolution where HLASM produces results which would be incorrect in AMODE 64. It's so bizarre a case that I doubt any programmers are relying on the behavior. HLASM appears to ignore overflows in base-displacement resolution. I consider this a bug that should be corrected. But I haven't reported it.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
