With the exception of XL, the linkage conventions for main and subroutines are the same. Of course, there are differences in the PLIST, but that's a separate issue.
Bottom line: expect bugs if you don't save the top halves as documented. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Edwards [mutazi...@gmail.com] Sent: Thursday, February 2, 2023 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Thu, 2 Feb 2023 16:38:38 +0000, Peter Relson <rel...@us.ibm.com> wrote: >I couldn't find the original post for this thread even in the archives, so I >don't know what this has to do with GETMAIN, or where "LOC=32" came into >things since the parameter is LOC=31. Here is the first post: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.ua.edu%2Fcgi-bin%2Fwa%3FA2%3Dind1805%26L%3DIBM-MAIN%26P%3DR16285&data=05%7C01%7Csmetz3%40gmu.edu%7C66e9a1f6c4904ab58d8c08db056de9aa%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638109741866545864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BE71z9NlDsxXzNVbkcshmsdWNaMLOnO5VLWti%2FdzeSE%3D&reserved=0 >I am exactly executing in AMODE 64. >And so I need the high halves to be clear at all times. >Because I am using pure S/370 instructions. > >I'll bite. Why would you choose to run in AMODE 64 if you are trying to >restrict yourself to S/370 instructions? So that I can potentially access the 2 GiB to 4 GiB region, using a "properly-written" S/370 program (that runs perfectly fine as AM24). >And why not even S/390 instructions, let alone z/Architecture instructions? You can choose whatever level you want, and the program will be upwardly compatible. You can actually choose S/360 if you want, capable of running as AM32 on a 360/67 and it will still run on AM64 on z/Arch. There are a few things the application needs to do itself, and I was trying to identify them. >Further, "need the high halves to be clear at all times" is not true. You only >would need the high halves (PLUS bit 32) to be zero for a register used to >access data and only at that point. That's not correct. You can (randomly) get access to the 2 GiB to 4 GiB region by using IARV64 (with or without a USE_2G... parameter). If you are lucky, you will be in a position to set the high bit of the lower 32 bits to 1 as part of accessing that new memory. My original post was a suggestion to get rid of that "randomly". But on top of that, I was looking for a z/OS change to guarantee the high halves were zero. And the new information is that I don't need that guarantee. I can make my S/370 applications "more-properly-written" by taking clear of clearing the high halves themselves, without being dependent on z/OS. >At a minimum, you are surely violating linkage conventions by not preserving >the high halves of any regs 2-14 that you might use. >(BAKR is not a S/370 instruction; if you allow for use of BAKR then you can >conform to linkage conventions without needing to use a zArch instruction such >as STMG or STMH) There are two linkage conventions I believe: 1. When one subroutine calls another subroutine. 2. When one program calls another program. I assume you are only concerned about (2). And I assume you're also not concerned about the situation of EXEC PGM= Yes you are correct. If program A is 64-bit (e.g. lots of LG as opposed to 32-bit L like program B) and does a LINK EP= to program B, and program B is using only 32-bit instructions, running as AM64, and does a traditional STM to save the lower halves, and then does LA instructions that wipe the higher half of registers, and program A is dependent on those being preserved, then it won't work. So a new convention would be needed that before doing a LINK EP= or ATTACH, you need to save your own registers. If program A is unable or unwilling to do that, then program B will need to be marked as AM31 instead. Once again, assuming program B has been "properly-written" such that it can run in AM24, 31, 32, 64. And yes, I'm aware that the 360/67 (AM32 capable) is no longer manufactured or sold. It still exists as a historical fact and as a concept, and if you are able to do AM64, AM32 will work anyway. I am identifying what is required from z/OS, and what is required from applications, in order to support making S/370 (or S/360) applications "fly" (work to the maximum theoretical limit - including potential theoretical changes to z/OS) on z/Arch. Note that there are other things of interest that I haven't mentioned in this thread, but I am reluctant to muddy the waters. BFN. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
