Hi
I have gotten the following code to work (with the help of Binyamin) as I will
list below but the problem is it is only being executed once and I am looping
thru a number of records
Seems like when I get to DUMBRK OFF +4; GO +4 it is removed and I would like to
process it for the next iteration of the code
LOAD 'MYTEST.LOAD(TESTPROG)'
GETMAIN 24 SP(0) LOC(BELOW) EQUATE(RGESVE)
GETMAIN 2 SP(0) LOC (BELOW) EQUATE(DUMBRK)
DUMBRK = X'0700'
AT +4( AT DUMBRK (COPY RGESVE 14R L(16); OFF +4; GO +4): COPY 14 RGESVE L(16);
RGEAVE+10=C'PARM1'; CALL TESTPROG.TESTPROG PARM(RGESVE) RETURN(DUMBRK))
TITLE('BREAK AT +4')
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Tony Harminc
Sent: Tuesday, July 3, 2018 12:47 PM
To: [email protected]
Subject: Re: TSO TEST breakpoint subcommand call either looping or not being
executed
On 2 July 2018 at 19:37, Joseph Reichman <[email protected]> wrote:
>> On Jul 2, 2018, at 4:31 PM, Binyamin Dissen <[email protected]>
>> wrote:
>>
>> If I understand you correctly and you repetitively want this to
>> occur, you will need:
>>
>> AT +8 (AT +C (off +c;call ......;go);go)
> Didn’t know you can put in parens to force sequence of execution
It's not that the parentheses are forcing the sequence of evaluation as in a
programming language. Rather, you can have as many stacked commands as you
like. (Well, doubtless there's some limit, but probably based only on the
total length.)
The second operand of the AT command is one or more commands to be executed
when the breakpoint is hit. You can have multiple commands separated by
semicolons, done in sequence. But any of those commands can be a new AT command
that may or may not be related to the first AT. That's what Binyamin has set up
for you.
So basically AT looks like this:
AT <address> (cmd1; cmd2; cmd3...)
and those cmds can be any TEST subcommand. Typically they are things like LIST
or LISTPSW, but they can also be AT or OFF.
Another thing to think carefully about when doing this kind of thing is where
your +n is relative to. The first AT you issue will be relative to the current
qualification, but the deferred AT will be relative to the qualification at the
time that it is executed, i.e.
when the first AT triggers. If you called a new module, the qualification may
have changed. In many cases it's best to use a more explicit address such as
module.csect.+n to be sure. Or you can issue a Q command to change the default.
Tony H.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
