Re: Saving Caller's 64-bit Regsiters
This problem is complex in theory but simple in (your) practice. Save/restore the lower halves with an STM/LM R14,R12,12(R13) on entry/exit. Save and restore the upper half of any register you destroy using a save area of your choice. The lower half of an otherwise unused register is good. A fullword in GETMAIN storage is good. AR 0 is good. QED Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Monday, January 24, 2022 11:15 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Saving Caller's 64-bit Regsiters "IBM Mainframe Assembler List" wrote on 01/24/2022 02:01:29 PM: > When I'm following save area chains in a dump, starting with R13, I look > at the second word. If it is an address, I know that the save area at that > address is a standard 72-byte save area. If it is F4SA, F5SA, F7SA, or F8SA, > offset X'80' from R13 is the address of the save area, and I know what > format it is. That is all well and good -- when you're looking at a dump. But I'm given to understand that none of that information is helpful when a called program receives control from a 2nd- or 3rd-party caller (i.e., any caller not written on-site) in terms of being able to tell how much storage the caller allocated for the savearea whose address is passed to the called program. Now, if I've got that wrong, then please enlighten me. Thanks. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Saving Caller's 64-bit Regsiters
I'm a bit confused. I understand that there is no way to determine whether the the caller has provided a 144-byte save area. However, I don't understand the issue for running the forward chain, assuming that all called routines have set the forward pointer, other than detecting the end of the chain. If +4 (word 2) is on a word boundary then the save area is either unused or is 72 bytes. If word 2 is FxSA (C6FxE2C1) then it is a 144-byte save area; anything else and it is invalid. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tom Marchant [00a69b48f3bb-dmarc-requ...@listserv.uga.edu] Sent: Monday, January 24, 2022 2:01 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Saving Caller's 64-bit Regsiters Replying to my own post to elaborate a little. When a program allocates a save area to pass to its callers, there is only one word, the second word, that it can use in the new save area. Everything else is reserved for the called program. The oldest documentation for the standard 72-byte save area that I have been able to find was published in 1966, but I'm sure the convention is much older than that. http://secure-web.cisco.com/1P_M4Kn04j805qzv6FEXzzkJc72DABsMkH1V50UzLffLOJYSS4IDUSU6IL5KElD85KF9b9vQS7m-XWUJr1Qs8y6ASTjLRALYYmRaA4xtaOHBIqDpn05SWhjrt5NLMqjG1wPj8RS5IQ7sAj_S5SsMpMoWLiZOj2fulcoqKBW9fCz0XQ0iABNvXXE8Nb_rZffVlfhoJSEczKuSHhVrfaG8OVOwhKHJR66rGn4iy-1jEL7I19pHoVfArekFfNZiADd6SySxwVYOcWgQx-58dxbEMzdlQfReAwQPrbt1QnhaWcVEl0M6p3QcQuUmYqM90zVY5EyJ1H36HURMPy-H3nTYj7k1_7lvqHfGWj0lkTBVNOGhstkxKYbY0Py-yHIqVrQRhZ0MKXkASwdOMM4UalZuJ_e5UNki-A3L7JKTJ30EAgEivK0wgFD54zy8Ad5MespwF/http%3A%2F%2Fwww.bitsavers.org%2Fpdf%2Fibm%2F360%2Fos%2FR01-08%2FC28-6541-1_Control_Program_Services_Apr66.pdf That manual says that the forward chain is optional. And so, the forward chain has never been reliable. When I'm following save area chains in a dump, starting with R13, I look at the second word. If it is an address, I know that the save area at that address is a standard 72-byte save area. If it is F4SA, F5SA, F7SA, or F8SA, offset X'80' from R13 is the address of the save area, and I know what format it is. It is a little like the problem of where to store the value of R13 upon entry to my program. It doesn't do me any good to store it in the save area that my caller passed me. So I save it in the save area that I allocate for the programs that I call. -- Tom Marchant On Mon, 24 Jan 2022 11:20:20 -0500, Tom Marchant wrote: >If your program can be called by a program that you don't control, and that >doesn't document that it provides something more, you have to assume >that you re only provided a 72-byte save area. > >There is no code that a program can provide in the first word of a save area >that could describe the save area. That is because the first word is defined >as for the use of language products. > >-- >Tom Marchant > >On Fri, 21 Jan 2022 09:32:07 -0500, Dave Clark >wrote: > >>My program is being >>called by REXX and I'm not aware of any documentation stating what kind of >>register save area REXX provides. That is why I asked and was wondering >>if there is, perhaps, a code in the first word of the save area that >>indicated the format used -- and, in the absences of such a code, the >>72-byte savearea is all there is.
Re: Saving Caller's 64-bit Regsiters
Especially since in z/OS it is now documented to pass a 144-byte save area to the step-level "PGM=" executable. AFAIK, what size save area either the online TMP or the batch TMP's (IKJEFTxx, IRXJCL) pass to Rexx is not documented. I don’t know what z/VSE documents as the program-level save area size these days; my last contact with VSE was VSE/SSX in the 1980's and VSE/SP in the early 1990's. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Gary Weinhold Sent: Monday, January 24, 2022 3:37 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Saving Caller's 64-bit Regsiters For both VSE and zOS, there is REXX documentation (VSE'sis at https://urldefense.com/v3/__https://www.ibm.com/docs/en/zvse/6.2?topic=packages-interface-writing-external-function-subroutine-code__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!a0PBz0tEROHBBSbMWczTByxVyibY8rfLa25PGXWyjFcOT9QI4Wz_Dfaz80YLJH1hrNo0gg$ that states that on entry to the called routine Register 13 contains the address of a register save area. What it doesn't say is how large that save area is. My assumption would be that it is 18 fullwords, just because it's not documented as being any different in VSE or z/OS and REXX is a 31-bit application. The fact that is not explicitly documented is troublesome, since as was pointed out, the writer of the routine sets the requirements for the users of the routine, and it would be reassuring to know that REXX always meets those requirements. On 2022-01-24 2:14 p.m., Dave Clark wrote: > "IBM Mainframe Assembler List" wrote > on > 01/24/2022 02:01:29 PM: >> When I'm following save area chains in a dump, starting with R13, I >> look at the second word. If it is an address, I know that the save >> area at > that >> address is a standard 72-byte save area. If it is F4SA, F5SA, F7SA, >> or > F8SA, >> offset X'80' from R13 is the address of the save area, and I know >> what format it is. > > That is all well and good -- when you're looking at a dump. > But I'm given to understand that none of that information is helpful > when a called program receives control from a 2nd- or 3rd-party caller > (i.e., any caller not written on-site) in terms of being able to tell > how much storage the caller allocated for the savearea whose address > is passed to the called program. Now, if I've got that wrong, then > please enlighten me. Thanks. > > > Sincerely, > > Dave Clark Gary Weinhold -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: Saving Caller's 64-bit Regsiters
On Friday I submitted this to IBM: Chapter 12. TSO/E REXX programming services of z/OS 2.5 TSO/E REXX Reference, SA32-0972-50 does not specify whether external functions are called with a 72-byte save area or a 144-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 Gary Weinhold [weinh...@dkl.com] Sent: Monday, January 24, 2022 3:37 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Saving Caller's 64-bit Regsiters For both VSE and zOS, there is REXX documentation (VSE'sis at https://www.ibm.com/docs/en/zvse/6.2?topic=packages-interface-writing-external-function-subroutine-code that states that on entry to the called routine Register 13 contains the address of a register save area. What it doesn't say is how large that save area is. My assumption would be that it is 18 fullwords, just because it's not documented as being any different in VSE or z/OS and REXX is a 31-bit application. The fact that is not explicitly documented is troublesome, since as was pointed out, the writer of the routine sets the requirements for the users of the routine, and it would be reassuring to know that REXX always meets those requirements. On 2022-01-24 2:14 p.m., Dave Clark wrote: > "IBM Mainframe Assembler List" wrote on > 01/24/2022 02:01:29 PM: >> When I'm following save area chains in a dump, starting with R13, I look >> at the second word. If it is an address, I know that the save area at > that >> address is a standard 72-byte save area. If it is F4SA, F5SA, F7SA, or > F8SA, >> offset X'80' from R13 is the address of the save area, and I know what >> format it is. > > That is all well and good -- when you're looking at a dump. But > I'm given to understand that none of that information is helpful when a > called program receives control from a 2nd- or 3rd-party caller (i.e., any > caller not written on-site) in terms of being able to tell how much > storage the caller allocated for the savearea whose address is passed to > the called program. Now, if I've got that wrong, then please enlighten > me. Thanks. > > > Sincerely, > > Dave Clark Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at http://secure-web.cisco.com/1cIgNo0EiEMdmDHVJsN4rpstJBctwj_pFa1VvrT-vVAvR8IMa9cRNHGowmgnC-CL_kJe1FRoJ1YoCpJyiS2RQ6X4tcIPJ0-nghTwib08SHqxhTygbcWdPgfY_wQskYU5Ih869H6DQghp_glZWRCEK86S05uXaU1OJEocmUeWRs6t8YAOUQQIdrA51gHjWQ2u_XYf7yRB44yPXrqkF1J3GvU5LMr9HYYsUigfRuvnjmHyUTbQzfiK-qFAri_EPeAgkwAylw2AVzRiqHACJ_VydCY_sXMTi6uJyllFVcSTB22nkIvWEJyHZmqzKxsjcq5Vp6CoahGVTSxC4AUnMJt3QA3Pnt_w-aXxQoqqYW_SOYvXgZi5b3nd87B_oWOXqceP_s8AvTUIVxEqpW4OqOoNce8Md-rSAbTPUDP9in4WBd2Jx0cctJPz8itd7ZJ7-dPwU/http%3A%2F%2Fwww.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Saving Caller's 64-bit Regsiters
For both VSE and zOS, there is REXX documentation (VSE'sis at https://www.ibm.com/docs/en/zvse/6.2?topic=packages-interface-writing-external-function-subroutine-code that states that on entry to the called routine Register 13 contains the address of a register save area. What it doesn't say is how large that save area is. My assumption would be that it is 18 fullwords, just because it's not documented as being any different in VSE or z/OS and REXX is a 31-bit application. The fact that is not explicitly documented is troublesome, since as was pointed out, the writer of the routine sets the requirements for the users of the routine, and it would be reassuring to know that REXX always meets those requirements. On 2022-01-24 2:14 p.m., Dave Clark wrote: "IBM Mainframe Assembler List" wrote on 01/24/2022 02:01:29 PM: When I'm following save area chains in a dump, starting with R13, I look at the second word. If it is an address, I know that the save area at that address is a standard 72-byte save area. If it is F4SA, F5SA, F7SA, or F8SA, offset X'80' from R13 is the address of the save area, and I know what format it is. That is all well and good -- when you're looking at a dump. But I'm given to understand that none of that information is helpful when a called program receives control from a 2nd- or 3rd-party caller (i.e., any caller not written on-site) in terms of being able to tell how much storage the caller allocated for the savearea whose address is passed to the called program. Now, if I've got that wrong, then please enlighten me. Thanks. Sincerely, Dave Clark Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Saving Caller's 64-bit Regsiters
"IBM Mainframe Assembler List" wrote on 01/24/2022 02:01:29 PM: > When I'm following save area chains in a dump, starting with R13, I look > at the second word. If it is an address, I know that the save area at that > address is a standard 72-byte save area. If it is F4SA, F5SA, F7SA, or F8SA, > offset X'80' from R13 is the address of the save area, and I know what > format it is. That is all well and good -- when you're looking at a dump. But I'm given to understand that none of that information is helpful when a called program receives control from a 2nd- or 3rd-party caller (i.e., any caller not written on-site) in terms of being able to tell how much storage the caller allocated for the savearea whose address is passed to the called program. Now, if I've got that wrong, then please enlighten me. Thanks. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Saving Caller's 64-bit Regsiters
Replying to my own post to elaborate a little. When a program allocates a save area to pass to its callers, there is only one word, the second word, that it can use in the new save area. Everything else is reserved for the called program. The oldest documentation for the standard 72-byte save area that I have been able to find was published in 1966, but I'm sure the convention is much older than that. http://www.bitsavers.org/pdf/ibm/360/os/R01-08/C28-6541-1_Control_Program_Services_Apr66.pdf That manual says that the forward chain is optional. And so, the forward chain has never been reliable. When I'm following save area chains in a dump, starting with R13, I look at the second word. If it is an address, I know that the save area at that address is a standard 72-byte save area. If it is F4SA, F5SA, F7SA, or F8SA, offset X'80' from R13 is the address of the save area, and I know what format it is. It is a little like the problem of where to store the value of R13 upon entry to my program. It doesn't do me any good to store it in the save area that my caller passed me. So I save it in the save area that I allocate for the programs that I call. -- Tom Marchant On Mon, 24 Jan 2022 11:20:20 -0500, Tom Marchant wrote: >If your program can be called by a program that you don't control, and that >doesn't document that it provides something more, you have to assume >that you re only provided a 72-byte save area. > >There is no code that a program can provide in the first word of a save area >that could describe the save area. That is because the first word is defined >as for the use of language products. > >-- >Tom Marchant > >On Fri, 21 Jan 2022 09:32:07 -0500, Dave Clark >wrote: > >>My program is being >>called by REXX and I'm not aware of any documentation stating what kind of >>register save area REXX provides. That is why I asked and was wondering >>if there is, perhaps, a code in the first word of the save area that >>indicated the format used -- and, in the absences of such a code, the >>72-byte savearea is all there is.
Re: Saving Caller's 64-bit Regsiters
When you say that it "makes no sense", I think you mean that you don't understand it. The second word of a save area cannot be set by the caller. Or, rather, if it is, it will be destroyed by the called program. How does a program know how a caller will use the save area that is passed to the programs that it calls? What is a program calls different programs that use different save area formats to save its caller's registers? A 64-bit program that used F4SA to save its caller's registers can call a 31-bit program that uses standard 72-byte save areas. An obvious example is a program that requests system services that require a 72-byte save area The use of the second word to signify how a program uses the save area is, I think, a good one. "F4SA", etc. end with X'C1', an odd value, and save areas have always been required to be on a fullword boundary. When I am reading a dump, I can follow the save areas back accurately, no matter what the mix of save area types is. XPLINK is, admittedly, rather more complicated. -- Tom Marchant On Fri, 21 Jan 2022 09:55:32 -0500, Tony Thigpen wrote: >It's worse than you think. There is a save area format tag literal for >the save area, but it's not set by the caller. It is set by the callee >saying how he used the previous save area in the chain. Which makes no >sense.
Re: Saving Caller's 64-bit Regsiters
If your program can be called by a program that you don't control, and that doesn't document that it provides something more, you have to assume that you re only provided a 72-byte save area. There is no code that a program can provide in the first word of a save area that could describe the save area. That is because the first word is defined as for the use of language products. -- Tom Marchant On Fri, 21 Jan 2022 09:32:07 -0500, Dave Clark wrote: >My program is being >called by REXX and I'm not aware of any documentation stating what kind of >register save area REXX provides. That is why I asked and was wondering >if there is, perhaps, a code in the first word of the save area that >indicated the format used -- and, in the absences of such a code, the >72-byte savearea is all there is.
