> Should/does HLASM require that the target of BR is within the owning CSECT?
No and no. (Or should I say "No/no"?) 1. No, the target of a BR is quite often in another CSECT, and quite happily so: L R15,=V(some_entry_point)/BR R15 or LM R14,R12,12(R13)/BR R14 2. No, it is not something the assembler has any way of knowing -- consider the second example above. Unlike what we have been discussing, where the assembler could "know" for example that 65535 is not a valid signed 16-bit quantity, or "know" that OTOH X'FFFF' is a valid representation of a signed 16-bit -1. (By "can know" I mean it would be generally discernible for an assembler of the general architecture of HLASM; I understand that internally the expression processor is not quite in the right place at the right time to figure this out, apparently.) Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Wednesday, March 1, 2017 1:59 PM To: [email protected] Subject: Re: HLASM anomaly On 2017-03-01, at 13:24, Steve Smith wrote: > ASMA320W is imho, a total wimp-out on IBM's behalf. There'd be less > confusion if this was flagged as an *error*, which it is. It may > sometimes generate what the user wants, but the user didn't specify it correctly. > > And the case where the assembler issues this for BR instructions is > egregiously wrong. > Should/does HLASM require that the target of BR is within the owning CSECT?
