I was once asked why the execute exception existed. That is, why not just let the hardware — or, in this odd case, the firmware — cascade down a chain of multiple EX instructions, ORing the bits of the R1 field with the subsequent target instruction, whatever instruction that might be. Aside from there being absolutely no practical reason for wasting circuits on such folly, the answer is obvious ... the EX instruction could target itself, and the CPU would get its knickers tied into a knot without an exception.
As to causing an execute exception (PIC 0003 [or 0083, 0203, or 0283 with all the PER and TX-related gorp]) without a base register, consider using EXECUTE RELATIVE LONG (EXRL) introduced in the z10. I know it's a "new" instruction, but it's 10 years new, so there's a good chance you've got it if you're IBM salesman has been doing her/his job in the past decade. Just have EXRL point to itself, and you've got what you need. Also, be aware that you can cause an execute exception by having an execute-type instruction (i.e., EX or EXRL) target a TABORT, TBEGIN, TBEGINC, or TEND instruction. This was not because the target was an execute instruction, but rather it was a convenient way of simplifying the design of the transactional-execution facility. Allowing a TX instruction to target a execute-type instruction was just too damn complicated. Finally, having spent the last 16 years working in architecture before I retired — where Linux developers will quickly remind you that zOS is not the only OS — I would encourage slightly more precise verbiage in describing program exceptions: S-0C# represents a z/OS system-completion code that often — but not always — corresponds to the hardware program-interruption code (PIC 000#). That is, you're fairly safe is equating S-0C1 with PIC-0001; however, when you get into the higher-numbered PICs, this no longer holds true. Furthermore, if you use the term S-0C# to a Linux developer, you may get a cross-eyed "WTF are you talking about?" look in response.
