Peter,
The SVC in question has but one purpose. To generate a system trace
table entry. The code within the SVC clears r15, and then branches r14.
Having an SVC that is like that is surely a bad idea if used in a customer
shop
in production where malicious use of that SVC could compromise system
serviceability.
I don't understand your comment. Unless by malicious use you mean that
the SVC would be executed over and over, just driving up overhead?
I honestly don't see that happening. The code to execute the SVC is
supplied by me, within a macro. The SVC number will be supplied by my
server code in my vendor table. The code dropped out by the macro checks
that my vendor entry is there, and that the SVC number is not 00's. And, I
would expect anyone assembling the macro into their code would certainly
control the logic flow with some kind of parm setting/flag byte convention.
If one of my customers ships their code to their customer with my code
embedded, and without any check on its execution, it wouldn't do anything
without my server being there, and up and running. And, if my server is
there, it would be pretty easy to identify the fact that the code in
question is executing this SVC without any controls on it.
I can't see any need to set a slip, or find it using IPCS in a dump.
That strikes me as a bit short-sighted unless this will never be used in a
customer shop.
Why is that short-sighted? Why would I ever set a slip on a BR R14? If
I need to know where the code is located in a dump, I can get the number
from my own data area, compute the offset into the SVC table, and then go
get it from that table.
--Dave
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
