Re: Testing g RTM routine
I was not aware of z/XDC's capabilities. That's good to know. Thanks, Dave. Bill Fairchild -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Cole Sent: Sunday, October 30, 2011 8:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Testing g RTM routine At 10/28/2011 11:43 AM, Bill Fairchild wrote: After following the advice in all the other previous answers, sooner or later you will still need to know how to test your SRB and its recovery routine. You probably won't be able to instruction-step or trace either very easily with TSOTEST or XDC. FWIW: z/XDC has *explicit* support for testing SRB code that is actually running within SRB environments. This support includes the ability to step through SRBs instruction by instruction, ... and includes the ability to debug locked code! Yes, there are some limitations, but they are less that what you might think, and within those limitations, z/XDC can be unexpectedly useful! Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.xdc.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 -- 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: Testing g RTM routine
At 10/28/2011 11:43 AM, Bill Fairchild wrote: After following the advice in all the other previous answers, sooner or later you will still need to know how to test your SRB and its recovery routine. You probably won't be able to instruction-step or trace either very easily with TSOTEST or XDC. FWIW: z/XDC has *explicit* support for testing SRB code that is actually running within SRB environments. This support includes the ability to step through SRBs instruction by instruction, ... and includes the ability to debug locked code! Yes, there are some limitations, but they are less that what you might think, and within those limitations, z/XDC can be unexpectedly useful! Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.xdc.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: Testing g RTM routine
CC, I concur and apologize .. I replied to Michael's email before I saw yours. Kind Regards Jim Thomas 617-233-4130 (mobile) 636-294-1014(res) j...@thethomasresidence.us (Email) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Craddock Sent: Thursday, October 27, 2011 9:00 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Testing g RTM routine On Oct 27, 2011, at 8:19 PM, Micheal Butz michealb...@optonline.net wrote: Would anyone know how to test the RTM routine of a SRB when I issue a schedule even though SRB activity is asynchronous it takes off automatically Michael, you're really playing with fire. Before you try any of that, please read the topics on SRB's and providing recovery in the authorized assembly language guide. Then read them again about a dozen times. If you don't have a very thorough understanding of system internals you're never going to get this stuff working safely. -- 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1834 / Virus Database: 2092/4578 - Release Date: 10/27/11 -- 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: Testing g RTM routine
Sir, Forgive me but what are you trying to accomplish and why ??. The information that you're looking for is not something that is 'easy' or for that matter, attempted by folks that have been coding for quite a while. Please do not take offence but you're trying to play with fire and if not properly (and or, very carefully) done, you can almost ensure an IPL to recover. Kind Regards Jim Thomas 617-233-4130 (mobile) 636-294-1014(res) j...@thethomasresidence.us (Email) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Micheal Butz Sent: Thursday, October 27, 2011 8:19 PM To: IBM-MAIN@bama.ua.edu Subject: Testing g RTM routine Hi, Would anyone know how to test the RTM routine of a SRB when I issue a schedule even though SRB activity is asynchronous it takes off automatically -- 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1834 / Virus Database: 2092/4578 - Release Date: 10/27/11 -- 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: Testing g RTM routine
I presume by RTM routine you mean FRR. It is not appreciably different than testing any other recovery routine. You have to do something so that that the mainline blows up. If you can run z/OS under VM, that could be ideal. P.S., Follow Chris's advice. Peter Relson z/OS Core Technology 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: Testing g RTM routine
After following the advice in all the other previous answers, sooner or later you will still need to know how to test your SRB and its recovery routine. You probably won't be able to instruction-step or trace either very easily with TSOTEST or XDC. What I do to test code that is sEEEriously difficult to test, at least when no VM or P/390 is available, is to spew OI instructions liberally throughout the code, typically putting one after each test-branch combination. Each such OI turns on a unique bit in some flag byte in some working storage somewhere. Then after the code has executed, I dump the working storage, study the inputs to the code, and see which flag bits were turned on. That tells me the exact path that my code took for that set of inputs. I may also store some intermediate values in registers into the same working storage. I have often used this technique to debug code that must run disabled for I/O interrupts, holding locks, in SRB mode, FRRs, etc. Bill Fairchild -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Micheal Butz Sent: Thursday, October 27, 2011 8:19 PM To: IBM-MAIN@bama.ua.edu Subject: Testing g RTM routine Hi, Would anyone know how to test the RTM routine of a SRB when I issue a schedule even though SRB activity is asynchronous it takes off automatically -- 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: Testing g RTM routine
Michael, When you mention testing the RTM routine, I have to ask, do you mean the FRR routine or the RMTR? I think most of the responders assume you meant the FRR. If you meant the RMTR, that is much more difficult, because you need a way to ensure that one or more SRB's remain that haven't been dispatched yet. There is a possible way to do this, but be aware that it should NEVER be done on a production system, and could be risky even on a general purpose test system (but that is true of all SRB related testing). All the testing I have done with this sort of code has been run on a z/OS system that is running as a VM guest that I have total control over, to the point of being able to set VM trace traps to interrupt the whole machine. The procedure I have used could result in the hanging of the target address space, and/or the whole system, so I am hesitant to provide much detail, other than to say that it requires multiple SRB's that perform a spin loop, and use of the PURGEDQ macro to drive the RMTR routine. === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Micheal Butz michealb...@optonline.net To: IBM-MAIN@bama.ua.edu Date: 10/27/2011 08:37 PM Subject: Testing g RTM routine Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hi, Would anyone know how to test the RTM routine of a SRB when I issue a schedule even though SRB activity is asynchronous it takes off automatically -- 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: Testing g RTM routine
I think Bill Fairchild's advice is very good advice because I do
something very similar.
I do, however, take things a step further. I put such code in a
trivial in-line framing macro of the form
| macro
| FRAMETEST diag=no --|yes
| . . .
|omit setb ('diag' eq 'no')
| . . .
| aif (omit).after_diag1
|diagnostic code
|.after_diag1 anop
| . . .
| aif (omit).after_diag2
|diagnostic code
|.after_diag2 anop
| . . .
| mend ,--FRAMETEST ends
ete., etc.
My own experience is that if I need diagnostic machinery for the
original version of a routine I shall need much of it again when I
make changes, and this simple scheme permits me to leave diagnostic
machinery in source code innocuously. I have also found that the
certainty that I and perhaps even others will see it over and over
again improves the quality of my diagnostic code.)
I suspect that Bill has other (unmentioned) machinery that largely
automates the implementation of the machinery he did describe, and you
will find it worthwhile to invest in such meta-machinery too.
One of the marks of a professional in this business is that he or she
has a growing and eventually large personal toolkit the contents of
which make like easier for him by eliminating much otherwise
deadening, repetitive work. Assembly-language programming is said to
be long-winded and detail-ridden, but these characteristics can be
much mitigated. (They cannot be entirely eliminated, and it is not
even desirable that they be eliminated, but that is a topic for
another day.)
John Gilmore, Ashland, MA 01721 - USA
--
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: Testing g RTM routine
On 10/28/2011 8:43 AM, Bill Fairchild wrote: After following the advice in all the other previous answers, sooner or later you will still need to know how to test your SRB and its recovery routine. You probably won't be able to instruction-step or trace either very easily with TSOTEST or XDC. What I do to test code that is sEEEriously difficult to test, at least when no VM or P/390 is available, is to spew OI instructions liberally throughout the code, typically putting one after each test-branch combination. I've had pretty good luck using SLIP IF for this sort of testing. But, it is tedious... -- Edward E Jaffe Chief Technology Officer 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
Testing g RTM routine
Hi, Would anyone know how to test the RTM routine of a SRB when I issue a schedule even though SRB activity is asynchronous it takes off automatically -- 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: Testing g RTM routine
On Oct 27, 2011, at 8:19 PM, Micheal Butz michealb...@optonline.net wrote: Would anyone know how to test the RTM routine of a SRB when I issue a schedule even though SRB activity is asynchronous it takes off automatically Michael, you're really playing with fire. Before you try any of that, please read the topics on SRB's and providing recovery in the authorized assembly language guide. Then read them again about a dozen times. If you don't have a very thorough understanding of system internals you're never going to get this stuff working safely. -- 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
