Re: writing color enhanced messes from rexx execs
Zoltan_Balogh [EMAIL PROTECTED] wrote: i have the same problem, now i can color an entire line, but i dont know how can i color only the part of the line.. I look for things at google but i cant find usefull things. Can you help me? And I replied: You cannot do this in XEDIT, or in linemode. You must use a program that knows how to do extended attributes, specifically the SA 3270 orders. XMENU, IOS3270 (maybe), DMS/CMS (maybe), and a host of others. Warning: writing such code yourself is non-trivial! Stanley Rarick [EMAIL PROTECTED] wrote: Au contraire - XEDIT is easy snip Perhaps I misunderstood the intent of Zoltan's question. Stanley is of course correct that you can use SET RESERVED and SET CTLCHAR to define multiple fields on a single line, but they are separate 3270 fields, with field marks between them. What I was referring to is the ability to define a line: byrg Where b is blue, y is yellow, r is reg, and g is green--with nothing between the characters. Apologies for the confusion. ...phsiii
Re: CMSCALL return code
True, and it is undoubtedly faster to use SR R15,R15 than it is to use LA R15,0 to zero the register - there are no storage fetches and real subtraction is not needed if the result can be predicted, as it can in this case. However, the discussion had more to do with fetches of boundary-aligned vs. non-aligned data. There was no mention of the optimum speed for getting either a specific or an arbitrary value loaded into a register. In this day of pipelined machines This is sort of reminiscent of the good old days, programming in 7080 Autocoder. Boeing insisted that the programmers use a MOVE macro because there were 26 different ways to move data from one storage location to another. It was expected that most programmers would use either their favorite way or the first one that popped into their heads if left on their own. The macro chose the optimal way, depending on the operand definitions. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stanley Rarick Sent: Friday, December 01, 2006 10:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code For a return code, LA R15,value is *much* faster than a L - only one storage fetch. Schuh, Richard wrote: I really would not have left it to chance, I would have defined a word-aligned constant rather than using a literal. However, it might not have been as chancy as it may seem. The literal pool is doubleword aligned and boundary alignment may have been a factor in determining where the literal resided. I would like to think that the 8-byte multiples are put at the front, the 4-byters next, then the twos followed by everybody else. In looking at an assembly listing, that seems to be the sequence. The first two literals in the program are =x'A00', the next =x'FF', etc. In the literal pool, all 4 byte entries (there were no 8 byte literals) precede the two byte literals and then come the ones of only 1 byte. Within each of these groups, the literals appear in the order in which they were defined. There were no long strings defined as literals in the particular listing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Don Russell Sent: Tuesday, November 21, 2006 3:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code Schuh, Richard wrote: I agree, it does seem non-intuitive. The initial SR R15,R15 was undoubtedly preparing for a default rc of zero. How the non-zero rc gets put into the register later is largely a matter of taste. In this case I probably would have chosen L R15,=X'...' - a habit learned, when machines were slower, based on the knowledge that they were mostly optimized for the LOAD instruction vs. any other way of putting data from memory into a register. If your habit was to use L Rx,=X'...' you were probably lucky in the old days the =X literal would not necessarily be word-aligned, causing two fetches to load the register, or, in the days when alignment really mattered... a program exception. Better to use L R15,=A(X'...') if alignment is a concern and you want to use literals. Then the literal IS aligned on a fullword boundary. The initial SR 15,15 is unlikely to be setting the default return code.. .it's clearing the register preparing for the different option bytes to be OR'd in. I agree the macro could (should?) have generated a single L instruction instead, but then what nits would we have to discuss? :-)
Re: CMSCALL return code
Sheesh, this goes way back to my good old Assembler diaper days when programmers really cared about performance instead of drag and drop solutions. Slightly off-topic: if I remember correctly, we argued intensely about zeroing a GPR and the performance differences between: - SR R15,R15 - XR R15,R15 - LA R15,0(not seriously considered by performance geeks) - L R15,=F'0' (considered for use only by amateur programmers coming from a BASIC or COBOL background and otherwise held in low esteem by real programmers). ;-) IIRC, the actual performance difference between SR and XR was different based more on specific processor models that anything else. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/04/2006 11:37 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: CMSCALL return code True, and it is undoubtedly faster to use SR R15,R15 than it is to use LA R15,0 to zero the register - there are no storage fetches and real subtraction is not needed if the result can be predicted, as it can in this case. However, the discussion had more to do with fetches of boundary-aligned vs. non-aligned data. There was no mention of the optimum speed for getting either a specific or an arbitrary value loaded into a register. In this day of pipelined machines This is sort of reminiscent of the good old days, programming in 7080 Autocoder. Boeing insisted that the programmers use a MOVE macro because there were 26 different ways to move data from one storage location to another. It was expected that most programmers would use either their favorite way or the first one that popped into their heads if left on their own. The macro chose the optimal way, depending on the operand definitions. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stanley Rarick Sent: Friday, December 01, 2006 10:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code For a return code, LA R15,value is *much* faster than a L - only one storage fetch. Schuh, Richard wrote: I really would not have left it to chance, I would have defined a word-aligned constant rather than using a literal. However, it might not have been as chancy as it may seem. The literal pool is doubleword aligned and boundary alignment may have been a factor in determining where the literal resided. I would like to think that the 8-byte multiples are put at the front, the 4-byters next, then the twos followed by everybody else. In looking at an assembly listing, that seems to be the sequence. The first two literals in the program are =x'A00', the next =x'FF', etc. In the literal pool, all 4 byte entries (there were no 8 byte literals) precede the two byte literals and then come the ones of only 1 byte. Within each of these groups, the literals appear in the order in which they were defined. There were no long strings defined as literals in the particular listing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Don Russell Sent: Tuesday, November 21, 2006 3:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code Schuh, Richard wrote: I agree, it does seem non-intuitive. The initial SR R15,R15 was undoubtedly preparing for a default rc of zero. How the non-zero rc gets put into the register later is largely a matter of taste. In this case I probably would have chosen L R15,=X'...' - a habit learned, when machines were slower, based on the knowledge that they were mostly optimized for the LOAD instruction vs. any other way of putting data from memory into a register. If your habit was to use L Rx,=X'...' you were probably lucky in the old days the =X literal would not necessarily be word-aligned, causing two fetches to load the register, or, in the days when alignment really mattered... a program exception. Better to use L R15,=A(X'...') if alignment is a concern and you want to use literals. Then the literal IS aligned on a fullword boundary. The initial SR 15,15 is unlikely to be setting the default return code.. .it's clearing the register preparing for the different option bytes to be OR'd in. I agree the macro could (should?) have generated a single L instruction instead, but then what nits would we have to discuss? :-) The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or
Re: CMSCALL return code
There is a new option now, especially with non-zero codes: LHI R15,4 No storage fetch. The subject of instruction timings on IBM-MAIN and ASSEMBLER-LIST comes up now and then. I point y'all to the archives of both lists. With the new z/Architecture pipelines and caches, sometimes what seems at first to be illogical instruction placement may actually be better. Hypothetical illustration example: LR4,RECPTRLoad address of pointer AHI R6,1 Add 1 to counter AHI R8,(-8) Some other strange counter CLI 16(R4),X'40' JE GOHERE The z/Architecture processor will execute the two AHI instructions while the base/displacement calculation and storage access for the L instruction is occurring, because it knows that R4 isn't affected by those instructions. By the time the CLI is hit R4 will contain the address and there is no delay that might occur if you code AHI R6,1 Add 1 to counter AHI R8,(-8) Some other strange counter LR4,RECPTRLoad address of pointer CLI 16(R4),X'40' JE GOHERE In this case, there might be a delay at the CLI. Speaking of branches there's been an interesting discussion recently about the branch-prediction logic in z/Architecture, which is why I demonstrate with the RI (or is it IR? I can never remember) instruction. Later, Ray -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Monday December 04 2006 12:02 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code Sheesh, this goes way back to my good old Assembler diaper days when programmers really cared about performance instead of drag and drop solutions. Slightly off-topic: if I remember correctly, we argued intensely about zeroing a GPR and the performance differences between: - SR R15,R15 - XR R15,R15 - LA R15,0(not seriously considered by performance geeks) - L R15,=F'0' (considered for use only by amateur programmers coming from a BASIC or COBOL background and otherwise held in low esteem by real programmers). ;-) IIRC, the actual performance difference between SR and XR was different based more on specific processor models that anything else. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/04/2006 11:37 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: CMSCALL return code True, and it is undoubtedly faster to use SR R15,R15 than it is to use LA R15,0 to zero the register - there are no storage fetches and real subtraction is not needed if the result can be predicted, as it can in this case. However, the discussion had more to do with fetches of boundary-aligned vs. non-aligned data. There was no mention of the optimum speed for getting either a specific or an arbitrary value loaded into a register. In this day of pipelined machines This is sort of reminiscent of the good old days, programming in 7080 Autocoder. Boeing insisted that the programmers use a MOVE macro because there were 26 different ways to move data from one storage location to another. It was expected that most programmers would use either their favorite way or the first one that popped into their heads if left on their own. The macro chose the optimal way, depending on the operand definitions. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stanley Rarick Sent: Friday, December 01, 2006 10:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code For a return code, LA R15,value is *much* faster than a L - only one storage fetch. Schuh, Richard wrote: I really would not have left it to chance, I would have defined a word-aligned constant rather than using a literal. However, it might not have been as chancy as it may seem. The literal pool is doubleword aligned and boundary alignment may have been a factor in determining where the literal resided. I would like to think that the 8-byte multiples are put at the front, the 4-byters next, then the twos followed by everybody else. In looking at an assembly listing, that seems to be the sequence. The first two literals in the program are =x'A00', the next =x'FF', etc. In the literal pool, all 4 byte entries (there were no 8 byte literals) precede the two byte literals and then come the ones of only 1 byte. Within each of these groups, the literals appear in the order in which they were defined. There were no long strings defined as literals in the particular listing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Don Russell Sent: Tuesday, November 21, 2006 3:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code Schuh, Richard wrote: I agree, it does seem non-intuitive. The initial SR
Re: CMSCALL return code
IIRC, the times for SR and XR were the same on the Amdahl machines, at least on the ones that came after the 470. They may have been the same on the 470, as well. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Monday, December 04, 2006 12:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code Sheesh, this goes way back to my good old Assembler diaper days when programmers really cared about performance instead of drag and drop solutions. Slightly off-topic: if I remember correctly, we argued intensely about zeroing a GPR and the performance differences between: - SR R15,R15 - XR R15,R15 - LA R15,0(not seriously considered by performance geeks) - L R15,=F'0' (considered for use only by amateur programmers coming from a BASIC or COBOL background and otherwise held in low esteem by real programmers). ;-) IIRC, the actual performance difference between SR and XR was different based more on specific processor models that anything else. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/04/2006 11:37 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: CMSCALL return code True, and it is undoubtedly faster to use SR R15,R15 than it is to use LA R15,0 to zero the register - there are no storage fetches and real subtraction is not needed if the result can be predicted, as it can in this case. However, the discussion had more to do with fetches of boundary-aligned vs. non-aligned data. There was no mention of the optimum speed for getting either a specific or an arbitrary value loaded into a register. In this day of pipelined machines This is sort of reminiscent of the good old days, programming in 7080 Autocoder. Boeing insisted that the programmers use a MOVE macro because there were 26 different ways to move data from one storage location to another. It was expected that most programmers would use either their favorite way or the first one that popped into their heads if left on their own. The macro chose the optimal way, depending on the operand definitions. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stanley Rarick Sent: Friday, December 01, 2006 10:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code For a return code, LA R15,value is *much* faster than a L - only one storage fetch. Schuh, Richard wrote: I really would not have left it to chance, I would have defined a word-aligned constant rather than using a literal. However, it might not have been as chancy as it may seem. The literal pool is doubleword aligned and boundary alignment may have been a factor in determining where the literal resided. I would like to think that the 8-byte multiples are put at the front, the 4-byters next, then the twos followed by everybody else. In looking at an assembly listing, that seems to be the sequence. The first two literals in the program are =x'A00', the next =x'FF', etc. In the literal pool, all 4 byte entries (there were no 8 byte literals) precede the two byte literals and then come the ones of only 1 byte. Within each of these groups, the literals appear in the order in which they were defined. There were no long strings defined as literals in the particular listing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Don Russell Sent: Tuesday, November 21, 2006 3:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code Schuh, Richard wrote: I agree, it does seem non-intuitive. The initial SR R15,R15 was undoubtedly preparing for a default rc of zero. How the non-zero rc gets put into the register later is largely a matter of taste. In this case I probably would have chosen L R15,=X'...' - a habit learned, when machines were slower, based on the knowledge that they were mostly optimized for the LOAD instruction vs. any other way of putting data from memory into a register. If your habit was to use L Rx,=X'...' you were probably lucky in the old days the =X literal would not necessarily be word-aligned, causing two fetches to load the register, or, in the days when alignment really mattered... a program exception. Better to use L R15,=A(X'...') if alignment is a concern and you want to use literals. Then the literal IS aligned on a fullword boundary. The initial SR 15,15 is unlikely to be setting the default return code.. .it's clearing the register preparing for the different option bytes to be OR'd in. I agree the macro could (should?) have generated a single L instruction instead, but then what nits would we have to discuss? :-) The information contained in this e-mail and any accompanying
Re: CMSCALL return code
Pipelining a machine and adding caches does throw a monkey wrench into the discussion. Add interrupts and you really have a mess. That is one reason why the performance guys like to preface every sentence with YMMV or It depends :-) -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ray Mullins Sent: Monday, December 04, 2006 12:40 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code There is a new option now, especially with non-zero codes: LHI R15,4 No storage fetch. The subject of instruction timings on IBM-MAIN and ASSEMBLER-LIST comes up now and then. I point y'all to the archives of both lists. With the new z/Architecture pipelines and caches, sometimes what seems at first to be illogical instruction placement may actually be better. Hypothetical illustration example: LR4,RECPTRLoad address of pointer AHI R6,1 Add 1 to counter AHI R8,(-8) Some other strange counter CLI 16(R4),X'40' JE GOHERE The z/Architecture processor will execute the two AHI instructions while the base/displacement calculation and storage access for the L instruction is occurring, because it knows that R4 isn't affected by those instructions. By the time the CLI is hit R4 will contain the address and there is no delay that might occur if you code AHI R6,1 Add 1 to counter AHI R8,(-8) Some other strange counter LR4,RECPTRLoad address of pointer CLI 16(R4),X'40' JE GOHERE In this case, there might be a delay at the CLI. Speaking of branches there's been an interesting discussion recently about the branch-prediction logic in z/Architecture, which is why I demonstrate with the RI (or is it IR? I can never remember) instruction. Later, Ray -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Monday December 04 2006 12:02 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code Sheesh, this goes way back to my good old Assembler diaper days when programmers really cared about performance instead of drag and drop solutions. Slightly off-topic: if I remember correctly, we argued intensely about zeroing a GPR and the performance differences between: - SR R15,R15 - XR R15,R15 - LA R15,0(not seriously considered by performance geeks) - L R15,=F'0' (considered for use only by amateur programmers coming from a BASIC or COBOL background and otherwise held in low esteem by real programmers). ;-) IIRC, the actual performance difference between SR and XR was different based more on specific processor models that anything else. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/04/2006 11:37 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: CMSCALL return code True, and it is undoubtedly faster to use SR R15,R15 than it is to use LA R15,0 to zero the register - there are no storage fetches and real subtraction is not needed if the result can be predicted, as it can in this case. However, the discussion had more to do with fetches of boundary-aligned vs. non-aligned data. There was no mention of the optimum speed for getting either a specific or an arbitrary value loaded into a register. In this day of pipelined machines This is sort of reminiscent of the good old days, programming in 7080 Autocoder. Boeing insisted that the programmers use a MOVE macro because there were 26 different ways to move data from one storage location to another. It was expected that most programmers would use either their favorite way or the first one that popped into their heads if left on their own. The macro chose the optimal way, depending on the operand definitions. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stanley Rarick Sent: Friday, December 01, 2006 10:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code For a return code, LA R15,value is *much* faster than a L - only one storage fetch. Schuh, Richard wrote: I really would not have left it to chance, I would have defined a word-aligned constant rather than using a literal. However, it might not have been as chancy as it may seem. The literal pool is doubleword aligned and boundary alignment may have been a factor in determining where the literal resided. I would like to think that the 8-byte multiples are put at the front, the 4-byters next, then the twos followed by everybody else. In looking at an assembly listing, that seems to be the sequence. The first two literals in the program are =x'A00', the next =x'FF', etc. In the literal pool, all 4 byte entries (there were no 8 byte literals) precede the two byte literals and then come the ones of only 1 byte. Within
Re: CMSCALL return code
On Monday, 12/04/2006 at 02:33 PST, Schuh, Richard [EMAIL PROTECTED] wrote: Pipelining a machine and adding caches does throw a monkey wrench into the discussion. Add interrupts and you really have a mess. That is one reason why the performance guys like to preface every sentence with YMMV or It depends :-) ...and is why, unless we're in a performance-sensitive area of code, we avoid spending time worrying about the speed of a particular instruction (laden or unladen). You get into endless arguments that are religious in nature and based on 30-year-old machine designs. :-) Alan Altmark z/VM Development IBM Endicott
REXX Primer
Does anyone have the subject book in PDF format? Thanks, Richard Schuh
Re: CMSCALL return code
Another way to clear the register (not really recommended but it works :-) SRLR15,32 Mike Walter [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/04/2006 03:01 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: CMSCALL return code Sheesh, this goes way back to my good old Assembler diaper days when programmers really cared about performance instead of drag and drop solutions. Slightly off-topic: if I remember correctly, we argued intensely about zeroing a GPR and the performance differences between: - SR R15,R15 - XR R15,R15 - LA R15,0(not seriously considered by performance geeks) - L R15,=F'0' (considered for use only by amateur programmers coming from a BASIC or COBOL background and otherwise held in low esteem by real programmers). ;-) IIRC, the actual performance difference between SR and XR was different based more on specific processor models that anything else. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/04/2006 11:37 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: CMSCALL return code True, and it is undoubtedly faster to use SR R15,R15 than it is to use LA R15,0 to zero the register - there are no storage fetches and real subtraction is not needed if the result can be predicted, as it can in this case. However, the discussion had more to do with fetches of boundary-aligned vs. non-aligned data. There was no mention of the optimum speed for getting either a specific or an arbitrary value loaded into a register. In this day of pipelined machines This is sort of reminiscent of the good old days, programming in 7080 Autocoder. Boeing insisted that the programmers use a MOVE macro because there were 26 different ways to move data from one storage location to another. It was expected that most programmers would use either their favorite way or the first one that popped into their heads if left on their own. The macro chose the optimal way, depending on the operand definitions. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stanley Rarick Sent: Friday, December 01, 2006 10:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code For a return code, LA R15,value is *much* faster than a L - only one storage fetch. Schuh, Richard wrote: I really would not have left it to chance, I would have defined a word-aligned constant rather than using a literal. However, it might not have been as chancy as it may seem. The literal pool is doubleword aligned and boundary alignment may have been a factor in determining where the literal resided. I would like to think that the 8-byte multiples are put at the front, the 4-byters next, then the twos followed by everybody else. In looking at an assembly listing, that seems to be the sequence. The first two literals in the program are =x'A00', the next =x'FF', etc. In the literal pool, all 4 byte entries (there were no 8 byte literals) precede the two byte literals and then come the ones of only 1 byte. Within each of these groups, the literals appear in the order in which they were defined. There were no long strings defined as literals in the particular listing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Don Russell Sent: Tuesday, November 21, 2006 3:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code Schuh, Richard wrote: I agree, it does seem non-intuitive. The initial SR R15,R15 was undoubtedly preparing for a default rc of zero. How the non-zero rc gets put into the register later is largely a matter of taste. In this case I probably would have chosen L R15,=X'...' - a habit learned, when machines were slower, based on the knowledge that they were mostly optimized for the LOAD instruction vs. any other way of putting data from memory into a register. If your habit was to use L Rx,=X'...' you were probably lucky in the old days the =X literal would not necessarily be word-aligned, causing two fetches to load the register, or, in the days when alignment really mattered... a program exception. Better to use L R15,=A(X'...') if alignment is a concern and you want to use literals. Then the literal IS aligned on a fullword boundary. The initial SR 15,15 is unlikely to be setting the default return code.. .it's clearing the register preparing for the different option bytes to be OR'd in. I agree the macro could (should?) have generated a single L instruction instead, but then what nits would we have to discuss? :-) The information contained in this e-mail and any
Re: CMSCALL return code
Ha!! We only *WISH* we were based on a 30-year old machine design! ;-) Reminds me of a joke: last night I was out with ... oh, let's not go there. Is it really only Monday? Mike Walter Alan Altmark [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/04/2006 04:43 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: CMSCALL return code On Monday, 12/04/2006 at 02:33 PST, Schuh, Richard [EMAIL PROTECTED] wrote: Pipelining a machine and adding caches does throw a monkey wrench into the discussion. Add interrupts and you really have a mess. That is one reason why the performance guys like to preface every sentence with YMMV or It depends :-) ...and is why, unless we're in a performance-sensitive area of code, we avoid spending time worrying about the speed of a particular instruction (laden or unladen). You get into endless arguments that are religious in nature and based on 30-year-old machine designs. :-) Alan Altmark z/VM Development IBM Endicott The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: CMSCALL return code
Are you wishing that you were 30 years younger? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Monday, December 04, 2006 2:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMSCALL return code Ha!! We only *WISH* we were based on a 30-year old machine design! ;-) Reminds me of a joke: last night I was out with ... oh, let's not go there. Is it really only Monday? Mike Walter Alan Altmark [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/04/2006 04:43 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: CMSCALL return code On Monday, 12/04/2006 at 02:33 PST, Schuh, Richard [EMAIL PROTECTED] wrote: Pipelining a machine and adding caches does throw a monkey wrench into the discussion. Add interrupts and you really have a mess. That is one reason why the performance guys like to preface every sentence with YMMV or It depends :-) ...and is why, unless we're in a performance-sensitive area of code, we avoid spending time worrying about the speed of a particular instruction (laden or unladen). You get into endless arguments that are religious in nature and based on 30-year-old machine designs. :-) Alan Altmark z/VM Development IBM Endicott The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: CMSCALL return code
On: Mon, Dec 04, 2006 at 02:24:39PM -0800,Schuh, Richard Wrote: } IIRC, the times for SR and XR were the same on the Amdahl machines, at } least on the ones that came after the 470. They may have been the same } on the 470, as well. I do recall that on the Amdahl 470s, there was one pair of instructions which were often executed together many places in VM/370 where the order of which one was first mattered a lot for execution time. They could go in any order, but the IBM code usually executed them in the wrong order for the 470s. A large fraction of the Amdahl mods to run VM 370 took a sequence like: xx . yy . and changed that to: yy . xx . to squeeze out a few more microseconds of performance. I don't recall what difference (if any) the instruction order made on blue hardware. -- Rich Greenberg N Ft Myers, FL, USA richgr atsign panix.com + 1 239 543 1353 Eastern time. N6LRT I speak for myself my dogs only.VM'er since CP-67 Canines:Val, Red, Shasta Casey (RIP), Red Zero, Siberians Owner:Chinook-L Retired at the beach Asst Owner:Sibernet-L
[no subject]
Hi! We are installing DB2 V7.4 and have a -934 error during start up of server machine unde a z/VM 4.4 Level 0501. What sounds strange is that if we start server without saved segment support, no problems occurs. Our old data base is a SQL version 3.4, so saved segments grows a lot and we don´t know if this problem is because wrong definition of saved segments (using vmfsgmap exec) Since SQL is running in production and these saved segments have original IBM names, we did need to rename new ones. Bellow is where we put them: DB2RMGR 01400-02300 DB2ISQL 00B00-00B60 DB2SQLDS 008B0-00A2F DB2XRDS 01400-0237F DB2SP03 008B0-0237F -- This is DB Space Server machine has 128MB memory defined in directory. Since we guess that DB2 program directory is not complete about how to generated saved segments, we are trying to get some help and hints from VM-L gurus. Thanks a lot for help. Carlos São Paulo - Brazil
Re: REXX Primer
i know this is not in pdf format, but maybe this is what you need: http://publibz.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/DMSG8A01/CCONTENTS?DT=19921218093737 On 12/4/06, Schuh, Richard [EMAIL PROTECTED] wrote: Does anyone have the subject book in PDF format? Thanks, Richard Schuh
Re: REXX Primer
On 12/5/06, Zoltan Balogh [EMAIL PROTECTED] wrote: i know this is not in pdf format, but maybe this is what you need: http://publibz.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/DMSG8A01/CCONTENTS?DT=19921218093737 or maybe this page has a bit more possibility: http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss?CTY=USFNC=SRXPBL=SC24-5598-01 On 12/4/06, Schuh, Richard [EMAIL PROTECTED] wrote: Does anyone have the subject book in PDF format? Thanks, Richard Schuh
