Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!ucf1vm.BITNET!news From: news@ucf1vm.BITNET Newsgroups: comp.lang.asm370 Subject: SHARE and Assembler H Message-ID: <9103101549.AA15537@ucbvax.Berkeley.EDU> Date: 8 Mar 91 17:03:14 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: IBM 370 Assembly Programming Discussion List Distribution: inet Organization: The Internet Lines: 47 At SHARE 76 (last week), the Assembler H Committee of the Languages Project (of which I am Project Manager) completed review of a survey to be sent to all SHARE membership sites. This survey is being produced at the suggestion of IBM, to prove the "business case" for IBM to "open up" Assembler H, add the SLAC mods and other long overdue enhancements, and perhaps improve the Assemble debugging environment (specifically under MVS). In August of 89, we met with IBM Language Product management, to discuss the refusal of IBM to incorporate the SLAC mods into the Assembler H Program Product. These mods increase diagnostic reporting and programming flexibility, often free-up registers unnecessarily tied up for USINGs to map DSECTS imbedded in other DSECTs, and increase assembler speed and efficiency. IBM agreed that all of this would be nice, but stated that the general trend was toward decreasing Assembler development, and that there was no real case for what amounts to a major modification of Assembler H. We agreed to conduct a representative survey, to determine the need (or lack there of) for a modern Assembler product. IBM was not convinced by two side arguments: 1 The SLAC mods (specifically, flagging overlapping USINGs) allow detection of bugs in existing code (eg, there were bugs found in JES2 and JES3 simply by re-assembling these). 2 The SLAC mods allow Assembler H to run more efficiently; since PLS compiles into Assembler H, IBM would save their own machine cycles by incorporating the mods. SHARE and IBM agreed that the Assembler H Committee would help to determine the usage level of Assembler among SHARE sites, and submit a suite of (about 4 dozen) SHARE requirements for improving the product. John Ehrman suggested that, if IBM were going to modify the Assembler, this would be an "all-or-nothing" deal, so we added requirements to support all labels and such in an integrated TEST environment, replacing TSO test, perhaps extending the INSPECT product to support Assembler H code as well as C and PL/I. All suggestions, comments, and volunteers to review the SHARE requirements we are writing (or to word some of the as-of-yet-unwritten ones) are welcome!