@John P. Hartmann: Well, I didn't know you could LARL or JAS to an external symbol. Thanks. I do have *PROCESS SUPRWARN(215) in many programs now, and I don't quite understand why that message is issued on z/OS.
Backing up a bit, what ORG is harmful? I'm familiar with the harm caused by a "reset" ORG emitted from a macro, but that's not likely to be the case here. I had thought of using ORG *-4, or even CNOP 2,4 DC X'C0F1',V(BPX4GUI) ...which I can't imagine could cause any problem. But LARL is a more natural way to do it. The code following is a CALL (15),(...),MF=(E,...). CALL can be coerced into doing a JAS[L], but it's pretty annoying to do so. It's generally simpler and less redundant to just put the EPA into R15 yourself. And quite often the calling routine expects R15 to be so set. On Mon, Jun 20, 2016 at 12:25 PM, John P. Hartmann <[email protected]> wrote: > There are several problems in your snippet. First of all, V(x) is valid > only in a DC instruction or literal reference (which is another way of > saying DC instruction). Second, =v(x) will fail because llilf wants an > absolute value. > > This works: > > extern bpx4gui > larl bpx4gui > > or even (if I can presume a basr 14,15 following): > > jas 14,bpx4gui (there is even a jasl nowadays) > > You get warning 215 with object (that is, not goff); and the CMS loader > will likely not know what to do with the external reference (haven't tried). > > However, if your question came from z/OS, the jas[l] will work with a > program object and that is the way to do it. > > > On 06/20/2016 04:56 PM, Steve Smith wrote: > >> Why shouldn't this be allowed: >> >> 00000182 0000 0000 0000 00000000 294 LLILF >> R15,V(BPX4GUI) GET THE EPA >> ASMA044E Undefined symbol - V >> ASMA173S Delimiter error, expected blank - (BPX4GUI) >> >> -- sas
