Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
At 14:22 -0400 on 09/14/2010, George Henke wrote about Re: z/OS V1.12 differences and z196 (the new mainframe) imp: Which compromises the entire purpose of the SAVE/RESTORE Register Convention which has been held sacred since the beginning of S/360, PCP, and/or S cubed. If the 64-bit program calling the 24/31 bit program wants to insure the integrity of the high end of the registers, it is ITS responsibility to save them around the call. That is the function of the 64-bit storing Save Area formats. So long as the called program wants a old-style Format 1 Save area, the high end is subject to being altered. On Tue, Sep 14, 2010 at 1:28 PM, Binyamin Dissen bdis...@dissensoftware.com wrote: On Tue, 14 Sep 2010 11:08:59 -0500 Walt Farrell wfarr...@us.ibm.com wrote: :On Tue, 14 Sep 2010 10:26:30 -0500, McKown, John :john.mck...@healthmarkets.com wrote: : -Original Message- : From: IBM Mainframe Discussion List : [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin : Sent: Tuesday, September 14, 2010 10:23 AM : To: IBM-MAIN@bama.ua.edu : Subject: Re: z/OS V1.12 differences and z196 (the new : mainframe) impacts : On Tue, 14 Sep 2010 11:04:47 -0400, David Cole wrote: : Except for regs 0,1,15 your assertion is true. : The high halves of those regs are not preserved across any interface : unless otherwise documented. : This is in contradiction to a verbal statement he made at a : presentation several years earlier wherein he flatly stated that no : preexisting AMODE(24/31) program would ever behave differently (due : to the widening of the registers) when run in z/OS vis-a-vis OS/390. : Unfortunately, I don't have the video. : Ah, semantics! Can a program run in AMODE(24/31) in OS/390 : (in a supported configuration) and use grande registers? :Sure. Why not. I use them for 64 bit numbers where I used to use a register :pair. Can OS/390 run on z hardware? I don't remember anymore. But use of :Grande registers in application code cannot be stopped by the OS. Of course, :if you call other routines, you'd better store them yourself. Because :somebody else might be doing the same. :In this context, John, it seems to me that pre-existing means before :64-bit registers existed, and thus your programs that use 64-bit registers :don't count. Pre-existing programs would only use 32-bit registers, and :would not have any knowledge of the high-halves of the 64-bit registers, and :are not affected by this change. I have to agree with IBM in this context. Pre-Z programs did not use the top half and thus can run unchanged. New Z programs have to take into consideration that the entire 64 bits of R15-R1 can change. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On Wed, 15 Sep 2010 08:00:07 -0400, Robert A. Rosenberg wrote: If the 64-bit program calling the 24/31 bit program wants to insure the integrity of the high end of the registers, it is ITS responsibility to save them around the call. That is incorrect. As clearly documented in the Assembler Services Guide, quote Unless otherwise defined by the individual interface, the calling program should expect, upon return, that - The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged - The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged /quote So long as the called program wants a old-style Format 1 Save area, the high end is subject to being altered. There is no such thing as a format 1 save area. You are referring to a standard 72-byte save area. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On Wed, 15 Sep 2010 08:00:07 -0400 Robert A. Rosenberg hal9...@panix.com wrote: :At 14:22 -0400 on 09/14/2010, George Henke wrote about Re: z/OS V1.12 :differences and z196 (the new mainframe) imp: :Which compromises the entire purpose of the SAVE/RESTORE Register Convention :which has been held sacred since the beginning of S/360, PCP, and/or S :cubed. :If the 64-bit program calling the 24/31 bit program wants to insure :the integrity of the high end of the registers, it is ITS :responsibility to save them around the call. That is the function of :the 64-bit storing Save Area formats. So long as the called program :wants a old-style Format 1 Save area, the high end is subject to :being altered. I would distinguish between R15-R1 and the other registers. A program must maintain the integrity of the callers top half of R2-R14. Of course, if a 64Bit routine calls a routine that expects to be in AM31 in AM64, all bets are off. :On Tue, Sep 14, 2010 at 1:28 PM, Binyamin Dissen bdis...@dissensoftware.com : wrote: : On Tue, 14 Sep 2010 11:08:59 -0500 Walt Farrell wfarr...@us.ibm.com : wrote: : :On Tue, 14 Sep 2010 10:26:30 -0500, McKown, John : :john.mck...@healthmarkets.com wrote: : : -Original Message- : : From: IBM Mainframe Discussion List : : [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin : : Sent: Tuesday, September 14, 2010 10:23 AM : : To: IBM-MAIN@bama.ua.edu : : Subject: Re: z/OS V1.12 differences and z196 (the new : : mainframe) impacts : : On Tue, 14 Sep 2010 11:04:47 -0400, David Cole wrote: : : Except for regs 0,1,15 your assertion is true. : : The high halves of those regs are not preserved across any interface : : unless otherwise documented. : : This is in contradiction to a verbal statement he made at a : : presentation several years earlier wherein he flatly stated that no : : preexisting AMODE(24/31) program would ever behave differently (due : : to the widening of the registers) when run in z/OS vis-a-vis OS/390. : : Unfortunately, I don't have the video. : : Ah, semantics! Can a program run in AMODE(24/31) in OS/390 : : (in a supported configuration) and use grande registers? : :Sure. Why not. I use them for 64 bit numbers where I used to use a : register : :pair. Can OS/390 run on z hardware? I don't remember anymore. But use of : :Grande registers in application code cannot be stopped by the OS. Of : course, : :if you call other routines, you'd better store them yourself. Because : :somebody else might be doing the same. : :In this context, John, it seems to me that pre-existing means before : :64-bit registers existed, and thus your programs that use 64-bit : registers : :don't count. Pre-existing programs would only use 32-bit registers, and : :would not have any knowledge of the high-halves of the 64-bit registers, : and : :are not affected by this change. : I have to agree with IBM in this context. Pre-Z programs did not use the : top : half and thus can run unchanged. New Z programs have to take into : consideration that the entire 64 bits of R15-R1 can change. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On Tue, 14 Sep 2010 13:38:15 -0500, Mike Schwab wrote: On Tue, Sep 14, 2010 at 12:15 PM, Tony Harminc wrote: deleted Well, we had this discussion at great length a few years ago... The pre-existing 24- or 31-bit program that's been running for many years now gets called by a 64-bit program, issues a GETMAIN which now zeros the high half of 64-bit R1, does some stuff, and returns to its caller, restoring the only R1 it knows about, which is 32 bits. The 64-bit caller has had its R1 clobbered by calling the pre-existing program, even though the pre-existing program used no 64-bit instructions or services and restored R1 as it always has done, and as its documentation states. The programmer who wrote the 64-bit program should not expect that the bits 0-31 of registers 0, 1 and 15 are preserved. This is just like a 31 bit program calling a 24 bit program. You have to save your own registers and set up the with 24 bit addresses before calling the 24 bit program. No, you don't have to save your own registers if you are a 31-bit program calling a 24-bit program. You do, of course, have to ensure that the called program will get control in AMODE(24) and must expect that it will return in AMODE(24), but that is a very different discussion. An AMODE(64) program does not have to save its registers either. Read the Assembler Services Guide chapter on Linkage Conventions. System interrupts do have to restore all 64 bits of the register, but not calls. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
In listserv%201009141022331100.0...@bama.ua.edu, on 09/14/2010 at 10:22 AM, Paul Gilmartin paulgboul...@aim.com said: Ah, semantics! Can a program run in AMODE(24/31) in OS/390 (in a supported configuration) and use grande registers? Yes. You might want to ask a different question. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
At 09:46 -0500 on 09/15/2010, Tom Marchant wrote about Re: z/OS V1.12 differences and z196 (the new mainframe) imp: On Wed, 15 Sep 2010 08:00:07 -0400, Robert A. Rosenberg wrote: If the 64-bit program calling the 24/31 bit program wants to insure the integrity of the high end of the registers, it is ITS responsibility to save them around the call. That is incorrect. As clearly documented in the Assembler Services Guide, quote Unless otherwise defined by the individual interface, the calling program should expect, upon return, that - The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged - The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged /quote Please reread my statement. I am talking about an 64-bit program calling a 24/31-bit program (legacy or not) NOT just making a system call. The only way to insure that the high end of the registers are preserved after the return to the 64-bit program is to restore them after the return. Otherwise the 24/31-bit program may use the high ends (such as for arithmetic) but not bother to do the preservation itself. So long as the called program wants a old-style Format 1 Save area, the high end is subject to being altered. There is no such thing as a format 1 save area. You are referring to a standard 72-byte save area. Yes I mean the standard 72-bute SA. I thought it was documented as a Format 1 SA but did not have a word0 eye-catcher/magic-key. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On Wed, 15 Sep 2010 13:10:37 -0400, Robert A. Rosenberg wrote: At 09:46 -0500 on 09/15/2010, Tom Marchant wrote about Re: z/OS V1.12 differences and z196 (the new mainframe) imp: On Wed, 15 Sep 2010 08:00:07 -0400, Robert A. Rosenberg wrote: If the 64-bit program calling the 24/31 bit program wants to insure the integrity of the high end of the registers, it is ITS responsibility to save them around the call. That is incorrect. As clearly documented in the Assembler Services Guide, quote Unless otherwise defined by the individual interface, the calling program should expect, upon return, that - The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged - The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged /quote Please reread my statement. I am talking about an 64-bit program calling a 24/31-bit program (legacy or not) NOT just making a system call. Please read the Assembler Services Guide. The Linkage Conventions chapter is _not_ to describe the interface for making a system call. It describes the linkage conventions for normal programs. The first paragraph in that chapter reads: quote Linkage conventions are the register and save area conventions a program must follow when it receives control from another program or when it calls another program. It is important that all programs follow the linkage conventions described here to ensure that the programs can successfully pass control from one to the other while preserving register contents and parameter data that they need to run successfully. /quote The only way to insure that the high end of the registers are preserved after the return to the 64-bit program is to restore them after the return. Otherwise the 24/31-bit program may use the high ends (such as for arithmetic) but not bother to do the preservation itself. This is simply incorrect. The linkage conventions describe what each program must do to restore the caller's registers when returning. If you are calling a program that follows the linkage conventions describes in the Assembler Services Guide, you are assured that registers are saved as I quoted above. If you call a program that does not follow the linkage conventions, all bets are off. The linkage conventions do _not_ say that an AMODE(64) program must restore bits 0-31. It says that bits 0-63 of registers 2 through 13 and bits 0-31 of register 14 are unchanged. A program, regardless of AMODE, may not legitimately use the high halves of registers (except for 15, 0 and 1) without preserving them. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
At 9/13/2010 09:23 AM, Paul Gilmartin wrote: On Mon, 13 Sep 2010 06:35:45 -0600, Steve Comstock wrote: * GETMAIN now returns address of gotten area in R1 with the leftmost word being all binary zeros, so address can be treated as a 64-bit address Unconditionally? That would break subroutines that don't save/restore high order parts. (Or does R1 not matter?) -- gil Gil, I once raised a similar question with Peter Relson. He unequivocally asserted that no program can rely upon any part of (including the high halves of) the volatile registers (r15, r0 and r1) being preserved across system interfaces (unless the interface doc states otherwise). Here's the quote: At 3/18/2007 08:07 AM, Peter Relson wrote: Dave, Except for regs 0,1,15 your assertion is true. The high halves of those regs are not preserved across any interface unless otherwise documented. This is documented in the assembler services guide 2.1 Saving the Calling Program's Registers [snip] This is in contradiction to a verbal statement he made at a presentation several years earlier wherein he flatly stated that no preexisting AMODE(24/31) program would ever behave differently (due to the widening of the registers) when run in z/OS vis-a-vis OS/390. Unfortunately, I don't have the video. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On Tue, 14 Sep 2010 11:04:47 -0400, David Cole wrote: Except for regs 0,1,15 your assertion is true. The high halves of those regs are not preserved across any interface unless otherwise documented. This is in contradiction to a verbal statement he made at a presentation several years earlier wherein he flatly stated that no preexisting AMODE(24/31) program would ever behave differently (due to the widening of the registers) when run in z/OS vis-a-vis OS/390. Unfortunately, I don't have the video. Ah, semantics! Can a program run in AMODE(24/31) in OS/390 (in a supported configuration) and use grande registers? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Tuesday, September 14, 2010 10:23 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS V1.12 differences and z196 (the new mainframe) impacts On Tue, 14 Sep 2010 11:04:47 -0400, David Cole wrote: Except for regs 0,1,15 your assertion is true. The high halves of those regs are not preserved across any interface unless otherwise documented. This is in contradiction to a verbal statement he made at a presentation several years earlier wherein he flatly stated that no preexisting AMODE(24/31) program would ever behave differently (due to the widening of the registers) when run in z/OS vis-a-vis OS/390. Unfortunately, I don't have the video. Ah, semantics! Can a program run in AMODE(24/31) in OS/390 (in a supported configuration) and use grande registers? -- gil Sure. Why not. I use them for 64 bit numbers where I used to use a register pair. Can OS/390 run on z hardware? I don't remember anymore. But use of Grande registers in application code cannot be stopped by the OS. Of course, if you call other routines, you'd better store them yourself. Because somebody else might be doing the same. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-691-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On Tue, 14 Sep 2010 10:26:30 -0500, McKown, John john.mck...@healthmarkets.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Tuesday, September 14, 2010 10:23 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS V1.12 differences and z196 (the new mainframe) impacts On Tue, 14 Sep 2010 11:04:47 -0400, David Cole wrote: Except for regs 0,1,15 your assertion is true. The high halves of those regs are not preserved across any interface unless otherwise documented. This is in contradiction to a verbal statement he made at a presentation several years earlier wherein he flatly stated that no preexisting AMODE(24/31) program would ever behave differently (due to the widening of the registers) when run in z/OS vis-a-vis OS/390. Unfortunately, I don't have the video. Ah, semantics! Can a program run in AMODE(24/31) in OS/390 (in a supported configuration) and use grande registers? -- gil Sure. Why not. I use them for 64 bit numbers where I used to use a register pair. Can OS/390 run on z hardware? I don't remember anymore. But use of Grande registers in application code cannot be stopped by the OS. Of course, if you call other routines, you'd better store them yourself. Because somebody else might be doing the same. In this context, John, it seems to me that pre-existing means before 64-bit registers existed, and thus your programs that use 64-bit registers don't count. Pre-existing programs would only use 32-bit registers, and would not have any knowledge of the high-halves of the 64-bit registers, and are not affected by this change. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On 14 September 2010 12:08, Walt Farrell wfarr...@us.ibm.com wrote: This is in contradiction to a verbal statement he made at a presentation several years earlier wherein he flatly stated that no preexisting AMODE(24/31) program would ever behave differently (due to the widening of the registers) when run in z/OS vis-a-vis OS/390. Unfortunately, I don't have the video. [...] In this context, John, it seems to me that pre-existing means before 64-bit registers existed, and thus your programs that use 64-bit registers don't count. Pre-existing programs would only use 32-bit registers, and would not have any knowledge of the high-halves of the 64-bit registers, and are not affected by this change. Well, we had this discussion at great length a few years ago... The pre-existing 24- or 31-bit program that's been running for many years now gets called by a 64-bit program, issues a GETMAIN which now zeros the high half of 64-bit R1, does some stuff, and returns to its caller, restoring the only R1 it knows about, which is 32 bits. The 64-bit caller has had its R1 clobbered by calling the pre-existing program, even though the pre-existing program used no 64-bit instructions or services and restored R1 as it always has done, and as its documentation states. Anyway - it's over; IBM's not going to fix it now. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On Tue, 14 Sep 2010 11:08:59 -0500 Walt Farrell wfarr...@us.ibm.com wrote: :On Tue, 14 Sep 2010 10:26:30 -0500, McKown, John :john.mck...@healthmarkets.com wrote: : -Original Message- : From: IBM Mainframe Discussion List : [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin : Sent: Tuesday, September 14, 2010 10:23 AM : To: IBM-MAIN@bama.ua.edu : Subject: Re: z/OS V1.12 differences and z196 (the new : mainframe) impacts : On Tue, 14 Sep 2010 11:04:47 -0400, David Cole wrote: : Except for regs 0,1,15 your assertion is true. : The high halves of those regs are not preserved across any interface : unless otherwise documented. : This is in contradiction to a verbal statement he made at a : presentation several years earlier wherein he flatly stated that no : preexisting AMODE(24/31) program would ever behave differently (due : to the widening of the registers) when run in z/OS vis-a-vis OS/390. : Unfortunately, I don't have the video. : Ah, semantics! Can a program run in AMODE(24/31) in OS/390 : (in a supported configuration) and use grande registers? :Sure. Why not. I use them for 64 bit numbers where I used to use a register :pair. Can OS/390 run on z hardware? I don't remember anymore. But use of :Grande registers in application code cannot be stopped by the OS. Of course, :if you call other routines, you'd better store them yourself. Because :somebody else might be doing the same. :In this context, John, it seems to me that pre-existing means before :64-bit registers existed, and thus your programs that use 64-bit registers :don't count. Pre-existing programs would only use 32-bit registers, and :would not have any knowledge of the high-halves of the 64-bit registers, and :are not affected by this change. I have to agree with IBM in this context. Pre-Z programs did not use the top half and thus can run unchanged. New Z programs have to take into consideration that the entire 64 bits of R15-R1 can change. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
Which compromises the entire purpose of the SAVE/RESTORE Register Convention which has been held sacred since the beginning of S/360, PCP, and/or S cubed. On Tue, Sep 14, 2010 at 1:28 PM, Binyamin Dissen bdis...@dissensoftware.com wrote: On Tue, 14 Sep 2010 11:08:59 -0500 Walt Farrell wfarr...@us.ibm.com wrote: :On Tue, 14 Sep 2010 10:26:30 -0500, McKown, John :john.mck...@healthmarkets.com wrote: : -Original Message- : From: IBM Mainframe Discussion List : [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin : Sent: Tuesday, September 14, 2010 10:23 AM : To: IBM-MAIN@bama.ua.edu : Subject: Re: z/OS V1.12 differences and z196 (the new : mainframe) impacts : On Tue, 14 Sep 2010 11:04:47 -0400, David Cole wrote: : Except for regs 0,1,15 your assertion is true. : The high halves of those regs are not preserved across any interface : unless otherwise documented. : This is in contradiction to a verbal statement he made at a : presentation several years earlier wherein he flatly stated that no : preexisting AMODE(24/31) program would ever behave differently (due : to the widening of the registers) when run in z/OS vis-a-vis OS/390. : Unfortunately, I don't have the video. : Ah, semantics! Can a program run in AMODE(24/31) in OS/390 : (in a supported configuration) and use grande registers? :Sure. Why not. I use them for 64 bit numbers where I used to use a register :pair. Can OS/390 run on z hardware? I don't remember anymore. But use of :Grande registers in application code cannot be stopped by the OS. Of course, :if you call other routines, you'd better store them yourself. Because :somebody else might be doing the same. :In this context, John, it seems to me that pre-existing means before :64-bit registers existed, and thus your programs that use 64-bit registers :don't count. Pre-existing programs would only use 32-bit registers, and :would not have any knowledge of the high-halves of the 64-bit registers, and :are not affected by this change. I have to agree with IBM in this context. Pre-Z programs did not use the top half and thus can run unchanged. New Z programs have to take into consideration that the entire 64 bits of R15-R1 can change. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On Tue, Sep 14, 2010 at 12:15 PM, Tony Harminc t...@harminc.net wrote: deleted Well, we had this discussion at great length a few years ago... The pre-existing 24- or 31-bit program that's been running for many years now gets called by a 64-bit program, issues a GETMAIN which now zeros the high half of 64-bit R1, does some stuff, and returns to its caller, restoring the only R1 it knows about, which is 32 bits. The 64-bit caller has had its R1 clobbered by calling the pre-existing program, even though the pre-existing program used no 64-bit instructions or services and restored R1 as it always has done, and as its documentation states. Anyway - it's over; IBM's not going to fix it now. Tony H. This is just like a 31 bit program calling a 24 bit program. You have to save your own registers and set up the with 24 bit addresses before calling the 24 bit program. System interrupts do have to restore all 64 bits of the register, but not calls. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On Tue, 14 Sep 2010 14:22:46 -0400 George Henke gahe...@gmail.com wrote: :Which compromises the entire purpose of the SAVE/RESTORE Register Convention :which has been held sacred since the beginning of S/360, PCP, and/or S :cubed. In what way? R15-R1 are documented as volatile. If you want to save them across system calls, you need to so it yourself. If you want to save all 64 bits, you need to do it yourself. No pre-Z program is affected as the top halves did not exist, thus nothing is broken. :On Tue, Sep 14, 2010 at 1:28 PM, Binyamin Dissen bdis...@dissensoftware.com : wrote: : On Tue, 14 Sep 2010 11:08:59 -0500 Walt Farrell wfarr...@us.ibm.com : wrote: : :On Tue, 14 Sep 2010 10:26:30 -0500, McKown, John : :john.mck...@healthmarkets.com wrote: : : -Original Message- : : From: IBM Mainframe Discussion List : : [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin : : Sent: Tuesday, September 14, 2010 10:23 AM : : To: IBM-MAIN@bama.ua.edu : : Subject: Re: z/OS V1.12 differences and z196 (the new : : mainframe) impacts : : On Tue, 14 Sep 2010 11:04:47 -0400, David Cole wrote: : : Except for regs 0,1,15 your assertion is true. : : The high halves of those regs are not preserved across any interface : : unless otherwise documented. : : This is in contradiction to a verbal statement he made at a : : presentation several years earlier wherein he flatly stated that no : : preexisting AMODE(24/31) program would ever behave differently (due : : to the widening of the registers) when run in z/OS vis-a-vis OS/390. : : Unfortunately, I don't have the video. : : Ah, semantics! Can a program run in AMODE(24/31) in OS/390 : : (in a supported configuration) and use grande registers? : :Sure. Why not. I use them for 64 bit numbers where I used to use a : register : :pair. Can OS/390 run on z hardware? I don't remember anymore. But use of : :Grande registers in application code cannot be stopped by the OS. Of : course, : :if you call other routines, you'd better store them yourself. Because : :somebody else might be doing the same. : :In this context, John, it seems to me that pre-existing means before : :64-bit registers existed, and thus your programs that use 64-bit : registers : :don't count. Pre-existing programs would only use 32-bit registers, and : :would not have any knowledge of the high-halves of the 64-bit registers, : and : :are not affected by this change. : I have to agree with IBM in this context. Pre-Z programs did not use the : top : half and thus can run unchanged. New Z programs have to take into : consideration that the entire 64 bits of R15-R1 can change. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On 9/14/2010 8:26 AM, McKown, John wrote: Sure. Why not. I use them for 64 bit numbers where I used to use a register pair. Can OS/390 run on z hardware? I don't remember anymore. But use of Grande registers in application code cannot be stopped by the OS. Of course, if you call other routines, you'd better store them yourself. Because somebody else might be doing the same. OS/390 V2R10 was the first release to support machines with z/Architecture. All prior releases will run only in ESA/390 mode. In that mode, the high halves don't exist. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
I once raised a similar question with Peter Relson. He unequivocally asserted that no program can rely upon any part of (including the high halves of) the volatile registers (r15, r0 and r1) being preserved across system interfaces (unless the interface doc states otherwise). Here's the quote: At 3/18/2007 08:07 AM, Peter Relson wrote: Dave, Except for regs 0,1,15 your assertion is true. The high halves of those regs are not preserved across any interface unless otherwise documented. I freqently use the full 64-bit R0, R1 and/or R15 registers in 'normal' 31-bit mode programs when I want to do some Grande computing without saving and restoring the upper halves of these registers. This seemed ok after carefully reading the available documentation. Haven't had problems so far Fred! - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/OS V1.12 differences and z196 (the new mainframe) impacts
For the last five or six years, August / September has been
a very busy time for me. This is when the IBM publications
for the new release of z/OS become available, and I download
these pubs and read them, looking for changes that impact
your applications programmers.
Then I update the courses I'm responsible for wherever the new
changes impact the course content.
Then I publish a brief synopsis of these changes to my opt-in
list and then various listservs and individual clients. So here
we go ...
This year the new release of z/OS is V1R12. There were
only a few aspects that may be useful to the typical
application programmer. But the availability of the new
mainframe line, the z196, impacts several of my courses.
The usefulness of any particular feature will vary from
person to person, of course; I figure if you see something
that looks helpful to you that you can check the docs
(or, of course, schedule a class!)
Highlights:
* New mainframe adds over 100 hardware instructions
* Minor changes to some z/OS UNIX commands
* New C/C++ functions to work with dates after 2038
* New VSAM ability to reclaim unused space dynamically
As usual, all of my courses that discuss any of the above
topics have been updated to reflect these changes /
enhancements. Let me know if you're aware of any other
training vendor who does that!
Now, for the next level of detail ...
_For the Assembler programmer in you_
The new z196 system introduces over 100 new instructions!
Discussion of these have been folded into the fourth course of
my z/OS Assembler series of courses; I've also re-named these
courses (while retaining the general content), so now the
curriculum is:
C410 z/OS Assembler Programming Part 1: Beginnings
C414 z/OS Assembler Programming Part 2: Interfaces
C416 z/OS Assembler Programming Part 3: Update
C500 z/OS Assembler Programming Part 4: z/Architecture and z/OS
visit
http://www.trainersfriend.com/Assembler_%20courses/assemcurric.htm
for details
Also added to the last course in the above list:
* BSAM READ and WRITE allow buffer above the bar,
using new paramter SF64 or SF64P
* CALL, LINK, LINKX, XCTL, XCTLX now document parameters
PLIST4={YES|NO} - parameter list entries are 4 bytes or not
PLIST8={YES|NO} - parameter list entries are 8 bytes or not
PLIST8ARALETS={YES|NO}
- for caller in AR mode, YES indicates 8 bytes-per-entry
parameter list is to be followed by the 4 bytes-per-entry
ALET list
* Macro IEABRCX extends IEABRC:
IEABRCX {DEFINE|PUSH|DISABLE|ENABLE|POP}
* GETMAIN now returns address of gotten area in R1 with the
leftmost word being all binary zeros, so address can be
treated as a 64-bit address
* Binder RMODE option has new suboption {INITIAL|COMPAT}
for use when RMODE(SPLIT) is not used; INITIAL indicates
RMODE value applies to all initial load classes in all
segments, while COMPAT indicates the RMODE value applies
to all initial load classes in the first segment only
(Beats the heck out of me what the practical implications are!)
_Various interesting developments_
Support for EAV (Extended Address Volumes) continues
to expand; with this release, the following kinds of
data sets may reside in the Extended Address Space
(EAS) of EAVs: VSAM, zFS (but not HFS), sequential,
PDS, PDSE, BDAM, and data sets with undefined DSORGs;
this is still not for VTOCs, VTOC indices, or page
data sets.
Support for the Large Block Interface (LBI) (blocksizes
greater than 32K) has been enhanced, sort of. We find
this somewhat contradictory paragraph in the Using
Data Sets publication:
The large block interface (LBI) lets your
program handle much larger blocks with BSAM
or QSAM. On the current level of the system
you can use LBI with BSAM, BPAM, and QSAM
for any kind of data set except unit record
or a TSO/E terminal. Currently blocks of more
than 32 760 bytes are supported only on tape,
dummy data sets, and BSAM UNIX files.
The last sentence seems to negate the previous sentence.
So, does LBI currently support BPAM? Apparently so,
but only if the data set is on tape. But, of course,
tape does not support BPAM.
Support for the new HFS / zFS filetype of RECORD
is expanded by being included in various shell commands
(e.g.: cp, extattr, ls, mv)
The ohelp command is removed from omvs; the intent
aparently is: you should use the 'man' facility
The tsocmd shell command can run authorized TSO commands
The oedit command has been modified so it doesn't
support the source ascii command; to edit an ASCII file
you must use file tagging and tag the file as ISO-8859-1
There are nine new environment variables for use
in the C/C++ run-time for setting run time options
and such
There are new C/C++ functions to work with date/times
beyond the January 19, 2038 end of era date range; the
limit for these new functions is December 31,
C/C++ compiler now supports:
* compile option to generate z196 instructions
* compile
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On Mon, 13 Sep 2010 06:35:45 -0600, Steve Comstock wrote: * GETMAIN now returns address of gotten area in R1 with the leftmost word being all binary zeros, so address can be treated as a 64-bit address Unconditionally? That would break subroutines that don't save/restore high order parts. (Or does R1 not matter?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On 9/13/2010 7:23 AM, Paul Gilmartin wrote: On Mon, 13 Sep 2010 06:35:45 -0600, Steve Comstock wrote: * GETMAIN now returns address of gotten area in R1 with the leftmost word being all binary zeros, so address can be treated as a 64-bit address Unconditionally? That would break subroutines that don't save/restore high order parts. (Or does R1 not matter?) -- gil R1 does not matter. From the Assembler Services Guide: Unless otherwise defined by the individual interface, the calling program should expect, upon return, that * The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged * The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged . . . * When return information is provided in GPR 0, 1, and/or 15 (for example return and reason codes), only bits 32-63 of the register contain the returned value. [Interesting, returning a 64-bit address in R1 would seem to violate that last assurance; perhaps a system service such as GETMAIN is not on a par with a general subroutine; in any case, I can't see this new behavior as causing any harm to programs that follow these classic requirements. On further reflection, there is still the opening caveat: Unless otherwise defined by the individual interface.] -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On Mon, 13 Sep 2010 07:33:13 -0600, Steve Comstock wrote: R1 does not matter. From the Assembler Services Guide: Unless otherwise defined by the individual interface, the calling program should expect, upon return, that * The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged * The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged . Clarification: I'm not thinking of system services, but of a putative user program, AMODE 31, which has hitherto guaranteed that R1 is preserved. It does the conventional: STMR14,R12,12(R13) GETMAIN ... Stuff ... FREEMAIN LM R14,R12,12(R13) BR R14 Suddenly, with no change in either the calling or the called code, the caller will find that the top half of R1 is destroyed. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
On 9/13/2010 8:22 AM, Paul Gilmartin wrote: On Mon, 13 Sep 2010 07:33:13 -0600, Steve Comstock wrote: R1 does not matter. From the Assembler Services Guide: Unless otherwise defined by the individual interface, the calling program should expect, upon return, that * The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged * The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged . Clarification: I'm not thinking of system services, but of a putative user program, AMODE 31, which has hitherto guaranteed that R1 is preserved. Well guaranteeing that R1 is preserved does not follow the conventional standard (see quoted above), so it would be a rare program that did so. Furthermore, if this is a traditional program, it really was really only guaranteeing the low word (rightmost 32 bits) because it never had to concern itself with the lefmost 32 bits; in the code below, the low word is still maintained. I've been around long enough to never say never, because programmers will do the strangest things. But for all practical terms I can't see this raises any potential problems and it provides a nice little option for programs that want to run in AMODE64. (Recall that GETMAIN can't allocate storage above the bar, this new feature simply ensures the effective address is a 64-bit address if that's helpful.) It does the conventional: STMR14,R12,12(R13) GETMAIN ... Stuff ... FREEMAIN LM R14,R12,12(R13) BR R14 Suddenly, with no change in either the calling or the called code, the caller will find that the top half of R1 is destroyed. -- gil -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
