I doubt that you will find an airtight solution.. If someone issues an OPSYN to define or undefine the operation mnemonic of your choice, your assembly will take the wrong turn.
I fail to see how you would prevent that ... Kind regards, Abe Kornelis ========== Op 05/06/2019 om 19:13 schreef John McKown: > On Wed, Jun 5, 2019 at 11:57 AM Seymour J Metz <[email protected]> wrote: > >> No, O'opcode will tell you whether opcode is defined, and if defined, what >> type of opcode it is. &SYSOPT_CURR_OPTABLE and &SYSOPT_OPTABLE tell you >> what table the assembler is using. >> > Correct. Suppose you are on a z14 running z/OS 2.3. If you invoke the > assembler with something like: MACHINE(ZS-3) (which is a z9). Then > O'LOCHINZ will return "U" because LOCHINZ is not valid on a z9. At least, > that has been my observation when I play around with this piece of code on > a z14 running z/OS 2.3 with the parm MACHINE(ZS-3). That's why I wanted to > know a z14 only instruction. If O'it was "U", then the code would assemble > the STORAGE macro without an EXECUTE=NO parameter. Simple over optimization > on my part, but this is my current "learning vehicle" code and I am trying > to find "extreme boundries". > > > >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >>
