Why not change the Assembler to generate an error message when code uses the implied length of a DSECT name? I see no reason for writing such code other than to confuse the reader. And we should discourage that. The change could not cause hard to debug behaviour changes. It could, though, identify long-standing errors that no-one noticed yet.
Steve Hobson Je me presse de rire de tout, de peur d'être obligé d'en pleurer From: Paul Gilmartin <[email protected]> To: [email protected] Date: 07/08/2012 08:16 Subject: Re: length of DSECT Sent by: IBM Mainframe Assembler List <[email protected]> On Aug 6, 2012, at 20:38, Gainsford, Allen wrote: > On 7/08/12 1:41 PM, "John Gilmore" wrote: > >> If different behavior is required, the better thing to do is to >> introduce a new, and newly named, facility that provides it. > Or, I would say, a new option for an existing facility. > True enough. The sad thing is that this approach, while far more > backwardly compatible, can leave a translator (or any other tool or > facility, for that matter) supporting a lot of "broken" behaviours > indefinitely. The translator, or facility, or whatever, can become a > nightmare to maintain because it's so weighed down with the past. It also > becomes harder to use because the documentation becomes similarly weighed > down. > The pity is there's so little evidence of specification or design of HLASM. It jes' growed. A dreadful example is that divide checks evaluating arithmetic expressions are not reported as errors. And I have an example where base and displacement are successfully evaluated in an R[SX] instruction where an S-constant with the same argument in apparently the same context causes an error. -- gil Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
