Certainly he can write such a macro. Whether it is "wrong" or not depends upon, among other things, whether one of the older machines he needs to support is the one where he must do his development and testing work. If that is the case, then he will lack the ability to test INST on a machine where it is supported as a machine instruction, and it would be irresponsible for him to ship code he cannot test.
There are instances where it is beneficial to simulate a machine instruction with a macro for environments where the hardware does not support the machine instruction. However, every case must be evaluated on its own merits. Among other things, if the code is part of a product that is distributed OCO, it must either be multi-pathed to always select the correct implementation or be shipped in a separate version for each machine level. The benefits of exploiting the machine instruction where it is available must be weighed against the overhead of the code that selects the code path and the cost of testing on multiple machines. A blanket suggestion that such a macro is always a good idea is simply incorrect. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2013-04-13 17:51, John Gilmore wrote:
Kenneth Meyer's formulation <begin extract> I, among many, have to support older versions of the mainframe. This means using common instructions rather than the latest instructions. </end extract> is admirably clear and succinct. Its only defect is that it is wrong. If instruction INST is not available on some of the machines he must support he can write a macro definition called INST that mimics its behavior for use on these antediluvian machines, do very much the same thing IBM does for millicoded instructions, albeit somewhat less elegantly. John Gilmore, Ashland, MA 01721 - USA
