>As I see it, you have two problems.
>
>Firstly, you don't know the address of the control block to be monitored by SA
>SLIP in advance. Dynamic PER allows you to solve that issue if you can
>identify a point in the code where the storage has been allocated (get the ball
>rolling with an IF trap at that point).
>
>Secondly, you have not one control block, but hundreds of them. The PER
>hardware only allows one range to be defined, which is why you can only
>have one non-IGNORE SA trap "eligible for checking" at any one time. To
>monitor multiple control blocks, the range would have to start at the lowest
>address of any of the blocks, and end at the last byte of the block with the
>highest address (and covering anything in between if the blocks are not
>contiguous). You might be able to filter out unwanted updates using DATA
>(could be a challenge with so many blocks) or maybe with other traps using
>IGNORE or SUBTRAP, but still the overhead could be high.
>
>Unless you know for sure that the control block is being hit a program which
>is addressing the control block using reg 8, the TRDATA you specified may
>not trace what you want. If the damage really is being done by
>"gatewaypgm", and it always does have a particular register pointing to the
>block, you could perhaps consider an IF trap over the whole module, with
>DATA used to identify when the block gets damaged, but since that would
>cause a PER interrupt for every instruction in the module, the overhead
>could also be high.
This is pretty much the problem. The good news is that the control blocks are
obtained as an array at gateway startup. The bad news is, each block is used to
store 48 counters, a handful of status bytes and a handful of ECBs and...other
indentifying data. The block that defines a session is x'340' long, and I have
202 in my test gateway. I can watch the whole array, and I know the point in
the code where it is obtained and initialized. (Having trouble figuring out how
to specify the RANGE to indicate that location).
The storage that is corrupted is initialized at subtask startup and shouldn't
change ever, barring individual subtask failure and restart. Nearly every
subtask determines R8 at initialization time and it never changes; that's why I
think my TRDATA should be ok. The main task shuffles among the control blocks,
but always sets R8 to point to the one he wants, so it should be ok there too.
Is the TRDATA start address determined at the point when the SLIP is triggered?
I'm more and more certain that the failure happens in the primary task at the
time when IP signals an incoming connection, so the next time I can test it I'm
going just to watch that task, as much as possible.
Confidentiality Notice: This electronic message transmission, including any
attachment(s), may contain confidential, proprietary, or privileged information
from Chemical Abstracts Service ("CAS"), a division of the American Chemical
Society ("ACS"). If you have received this transmission in error, be advised
that any disclosure, copying, distribution, or use of the contents of this
information is strictly prohibited. Please destroy all copies of the message
and contact the sender immediately by either replying to this message or
calling 614-447-3600.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
