Re: Long displacement dependent USINGs now supported
On 11/17/2021 1:36 AM, Jonathan Scott wrote: We have just shipped the PTFs for APAR PH42050 which allows a dependent USING instruction to be resolved using a 20-bit signed displacement provided that the specified OPTABLE is one which supports instructions with that capability. | HH HH AA NN NN KK KK | HH HH NNN NN KK KK | TT HH HH AA AA NN KK KK | TT HH HH AA AA NN NN NN KK KK | TT HH HH AA AA NN NN NN KK KK | TT NN NN NN KKK | TT NN NN NN KKK | TT HH HH AA AA NN NN NN KK KK | TT HH HH AA AA NN KK KK | TT HH HH AA AA NN NNN KK KK | TT HH HH AA AA NN NN KK KK | TT HH HH AA AA NN N KK KK | | | YY YY UU UU | YY YY UU UU | YY YY OO OO UU UU | YY YY OO OO UU UU | YY YY OO OO UU UU | OO OO UU UU | YY OO OO UU UU | YY OO OO UU UU | YY OO OO UU UU | YY OO OO UU UU | YY | YY UU -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Base-less macros
> In that scenario, offset 4 of Xs save area will no longer contain > FnSA, and can thus be identified as the forward pointer of a 72-bytesave area. The point that several recent posts have been trying to make is that the contents of word 1 indicate how the registers were saved in the *previous* save area, not this one. You'd have to find the save area *after* X's save area to determine the format of X's save area, and the finding of the next save area is problematic without already knowing the format of X's save area. - mb
Re: MNOTE imbedded apostrophes / ASMA163W
Yes thank you very much this worked:
SETC 'C''R'''
_MNOTE SETC DOUBLE('')
MNOTE *,'&WHAT = _MNOTE'
generates the MNOTE:
2111+*, = C'R'
Re: Base-less macros
In that scenario, offset 4 of Xs save area will no longer contain FnSA, and can thus be identified as the forward pointer of a 72-byte save area. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Mark Boonie [boo...@us.ibm.com] Sent: Wednesday, December 1, 2021 2:09 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros > The one case where there could be an issue is if the > routine calls both code expecting a 72-byte save area and code > calling a 144-byte area. > > If the linkage conventions are followed, under what circumstances > would you be unable to follow the forward chain with a little bit of work? Didn't you just identify the circumstances? Suppose routine X calls both routine Y and routine Z with a 144-byte save area: - Routine X calls routine Y which is going to use the high-order halves of some registers. Routine Y updates routine X's save area with the saved 64-bit registers and a pointer to routine Y's new save area in location 136. - Routine Y returns to routine X. - Routine X calls routine Z which is only going to use the low-order halves of the registers. Routine Z updates routine X's save area with the saved 32-bit registers and a pointer to routine Z's new save area in word 2. Before routine Z returns, the save area for routine X (the one pointed pointed to by the backward pointer from Z's current save area) has two forward pointers: one to the no longer valid save area for routine Y, and one to the valid save area for routine Z. Scanning forward doesn't allow you to tell which one is correct. Unless by "linkage conventions" you mean calling a routine with a save area that is only as large as that which is required, so that X would need two different save areas for calling Y and Z? - mb
Re: Base-less macros
> The one case where there could be an issue is if the > routine calls both code expecting a 72-byte save area and code > calling a 144-byte area. > > If the linkage conventions are followed, under what circumstances > would you be unable to follow the forward chain with a little bit of work? Didn't you just identify the circumstances? Suppose routine X calls both routine Y and routine Z with a 144-byte save area: - Routine X calls routine Y which is going to use the high-order halves of some registers. Routine Y updates routine X's save area with the saved 64-bit registers and a pointer to routine Y's new save area in location 136. - Routine Y returns to routine X. - Routine X calls routine Z which is only going to use the low-order halves of the registers. Routine Z updates routine X's save area with the saved 32-bit registers and a pointer to routine Z's new save area in word 2. Before routine Z returns, the save area for routine X (the one pointed pointed to by the backward pointer from Z's current save area) has two forward pointers: one to the no longer valid save area for routine Y, and one to the valid save area for routine Z. Scanning forward doesn't allow you to tell which one is correct. Unless by "linkage conventions" you mean calling a routine with a save area that is only as large as that which is required, so that X would need two different save areas for calling Y and Z? - mb
Re: Base-less macros
My "Assuming that the caller has initialized the save area and subsequently used it in accordance with IBM linkage conventions" took into account what Peter wrote. If the caller does not follow the conventions, all bets are off. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Wednesday, December 1, 2021 1:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Nope! Read what Peter wrote. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Wednesday, December 1, 2021 10:27 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Assuming that the caller has initialized the save area and subsequently used it in accordance with IBM linkage conventions, offset 4-7 will contain 4 EBCDIC characters ending iin SA only if it is 144 bytest long; the forward link of a 72-byte save area should never be odd. The one case where there could be an issue is if the routine calls both code expecting a 72-byte save area and code calling a 144-byte area. If the linkage conventions are followed, under what circumstances would you be unable to follow the forward chain with a little bit of work? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Wednesday, December 1, 2021 10:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Charles wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote > the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Nope! Read what Peter wrote. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Wednesday, December 1, 2021 10:27 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Assuming that the caller has initialized the save area and subsequently used it in accordance with IBM linkage conventions, offset 4-7 will contain 4 EBCDIC characters ending iin SA only if it is 144 bytest long; the forward link of a 72-byte save area should never be odd. The one case where there could be an issue is if the routine calls both code expecting a 72-byte save area and code calling a 144-byte area. If the linkage conventions are followed, under what circumstances would you be unable to follow the forward chain with a little bit of work? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Wednesday, December 1, 2021 10:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Charles wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote > the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Assuming that the caller has initialized the save area and subsequently used it in accordance with IBM linkage conventions, offset 4-7 will contain 4 EBCDIC characters ending iin SA only if it is 144 bytest long; the forward link of a 72-byte save area should never be odd. The one case where there could be an issue is if the routine calls both code expecting a 72-byte save area and code calling a 144-byte area. If the linkage conventions are followed, under what circumstances would you be unable to follow the forward chain with a little bit of work? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Wednesday, December 1, 2021 10:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Charles wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote > the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Thanks for the clarification. I seem to be a slow learner. > It's perfectly fine to use high halves in AMODE 31 People seem to conflate AMODE 64 with the usage of high halves. Writing in AMODE 64 is kind of a big deal (been there, etc.). Using the high halves for arithmetic and such is a piece of cake. > Having a unique entry point for each AMODE can be a good approach Seems like a perfect approach. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Wednesday, December 1, 2021 7:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Charles wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote > the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Charles wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote > the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
