Re: Newer HLASM functions (was ...)
Regarding how you'd know, I have no idea. This wasn't done in an APAR. Regarding LR 15,R5 surely you provided the equate of R5 (or some macro did); fix/enhance the equate/macro. I see yregs, for example, which apparently is owned by DFSMS, has no facility for adding the register-size attribute. You might request that they do so. Regarding LR / CPYA vs LAE: They are not equivalent. Sometimes the difference doesn't matter; sometimes it does. Macros that are adjusted incrementally tend to stay on the conservative side. And the LR has existed forever. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newer HLASM functions (was ...)
On 7 March 2013 07:53, Peter Relson rel...@us.ibm.com wrote: [With respect to GR32=NO|YES on IHASDWA] Regarding how you'd know, I have no idea. This wasn't done in an APAR. So how did *you* find out? Word of mouth, stumbled across it in the macro, or an internal doc of some sort? Or are you perhaps the one who updated IHASDWA? Regarding LR 15,R5 surely you provided the equate of R5 (or some macro did); fix/enhance the equate/macro. Right - I provided (in a macro) R5 EQU5GR32 which is fine for the LR, but of course not for the CPYA. I also have an equate for the ARs AR5 EQU5AR which will work with the CPYA but not the LR. I could remove the GR32, but then we're back to the beginning. The whole point is to allow the assembler to detect certain inappropriate uses of symbols. I see yregs, for example, which apparently is owned by DFSMS, has no facility for adding the register-size attribute. You might request that they do so. That would just break SETRP for more people! Regarding LR / CPYA vs LAE: They are not equivalent. Sometimes the difference doesn't matter; sometimes it does. Sure. Macros that are adjusted incrementally tend to stay on the conservative side. And the LR has existed forever. Well, I would've thought that in this case LAE would be more conservative than adding the CPYA (if in AR mode). The LR is already parameterized, and will emit an LGR if in 64-bit mode. The bottom line is that I can't see a way to both use the TYPECHECK(REGISTER) option, and use SETRP in AR mode with RUB=(...). (Well, I can, of course - I changed RUB=(R5) to RUB=(5), thus avoiding the warning, but also avoiding the checking. Ed/John - help me out here! What's the right way of doing this (on my part or IBM's)? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newer HLASM functions (was ...)
On 3/7/2013 10:51 AM, Tony Harminc wrote: The bottom line is that I can't see a way to both use the TYPECHECK(REGISTER) option, and use SETRP in AR mode with RUB=(...). (Well, I can, of course - I changed RUB=(R5) to RUB=(5), thus avoiding the warning, but also avoiding the checking. FWIW, this is what we do with all register specifications to IBM macros. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newer HLASM functions (was ...)
On 3 March 2013 11:51, Ed Jaffe edja...@phoenixsoftware.com wrote: On 3/3/2013 8:19 AM, Peter Relson wrote: For what it's worth, IHASDWA was enhanced in z/OS 1.11 with a GR32=NO|YES option so that if you must use the HLASM optional function, you can do so. We will change every IHASDWA in every software product we have to code GR32=YES. THANKS for the great info! Thanks indeed, Peter. Two little things: How should we have expected to hear about this nice little update? It's not in the Data Areas, but then mapping macro keywords (like DSECT= and such), are not generally listed there. I can't find an APAR. Maybe for this kind of thing IBM-MAIN is just right. And I notice as I do some reworking to take advantage of this, that SETRP is now failing with RUB=(R5), because R5 is a GR32, and SETRP generates LR15,R5 CPYA 15,R5 one of which must surely provoke the HLASM warning. Would a single LAE not do the trick here? But there are others - sigh... Such a nice idea these Assembler Types. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Newer HLASM functions (was ...)
(Sorry, I couldn't keep doing that to Paul, so I changed the subject) Newer IBM macros rely on some newer (for various values of newer) assembler functions. But I'd guess that not one of them relies on a function that is a diagnostic function. Yes, macros for a z/OS release might indeed rely on the HLASM that accompanies that release. Most of the cases that I think we are talking about are diagnostic functions that can be turned on and off (such as by ACONTROL). The existence of old macros is one reason why the assembler team tends to make options of these not all or nothing but rather enable-able and disable-able. It is certainly very reasonable to enable a function for your code, disable it for some macro, then re-enable it. The SETRP example is one where SETRP was of course doing this long before HLASM created its option. For what it's worth, IHASDWA was enhanced in z/OS 1.11 with a GR32=NO|YES option so that if you must use the HLASM optional function, you can do so. As to coding your own expansions: feel free. But don't expect any sympathy or support (since doing so is not supported). You'd better get it right. Fortunately z/OS is not windoze so you can pretty much rely on the object code from your hand-coded source continuing to work from release to release (a migration action for a release should accompany a necessary change.) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newer HLASM functions (was ...)
On 3/3/2013 8:19 AM, Peter Relson wrote: For what it's worth, IHASDWA was enhanced in z/OS 1.11 with a GR32=NO|YES option so that if you must use the HLASM optional function, you can do so. We will change every IHASDWA in every software product we have to code GR32=YES. THANKS for the great info! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
