On 2 March 2013 20:16, Peter Relson <rel...@us.ibm.com> wrote: > Paul Gilmartin wrote >>breaks commonly used conventions or newer HLASM functions >>(e.g. SETRP),
Actually Iwrote that bit, so putting Paul in the subject line was even worse... :-) > Can you be more specific? I'm at home, so not as specific as I can be on Monday. But SETRP generates a NOPR with an expression (related to the SDWA, I think) obviously intended (and I think commented) to fail if the length is not 0. However HLASM doesn't think the expression is a likely register value - a legal one, certainly - but still worth a warning if you have registers EQUated with the GR or GR32 or GR64 option. > It's pretty likely that SETRP did not break anything (unless it was 30 > years ago). I could easily believe that some things might not work with > newer HLASM functions (but I'm curious "which"). I don't think I said that SETRP breaks function, but it makes it hard to use the new features. It would be simple to generate something that the HLASM doesn't think is a register reference, e.g. 0AL1(...) or the like. > IBM typically makes no claim that its existing macros work with newer > HLASM functions, unless otherwise stated. I'll bet that your code makes no > such claim either. Fair enough. But I think of "my" code as including those documented and common IBM macros. If I have to choose between not using SETRP and giving the assembler enough info to help diagnose some of my finger checks, well of course I have to use SETRP. Maybe it's not to hard to #pragma (as the C folks would put it) around it, but I don't think I should have to. In fairness, SETRP is a very rare example of this kind of problem in supervisor macros. Non working examples (which started this thread), and bad machine-generated "assembler" from PL/X are much more frequent problems. > Use new HLASM functions on your own code at your own discretion; don't > presume they work on others' code. Well, that's tricky... Newer IBM macros rely on some newer (for various values of newer) assembler functions. Realistically, if no IBM mainstream macros are guaranteed to work when certain newer assembler functions are used, then no application programs that invokes z/OS services can use those functions. Surely these functions are not meant for John Gilmore's presumably isolated table generation schemes alone... I will dig up the REXX and VxAM details when I can. The VxAM macro does not allow any positional operands, and MNOTEs to that effect if you supply one. This makes it impossible to use a comment or update flags on the line that invokes the macro. The normal way around this is to supply a single comma as the "positional operand", but this macro (can't remember which one) presumably checks N'&SYSLIST and flunks it. Details on Monday if you care. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
