If your code that you want traced in the System Trace table runs authorized, you can also use the TRACE instruction. I did that once to shoot a weird timing problem.
Bill Fairchild -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Dave Day Sent: Sunday, January 01, 2012 12:59 PM To: [email protected] Subject: Re: Question on adding an SVC routine dynamically to a running system I will change the logic that establishes the SVC to add the module to LPA. Your point of making it easier to identify things when looking at a dump is a valid one. I was using the trace entry in the trace table as a trigger mechanism for my code. By matching entries, I can give count and elapsed time in my reporting logic. As to causing the trace table to wrap...dunno what to say. There is so much activity getting traced already by default that adding some extra entries for a user SVC just isn't going to be that much. I've got it working, but really don't like the fact that it is limited to PASN=HASN, and TCB mode code only. I'm going to try to accomplish the same thing using PTRACE. If I get that working, I'll can the SVC. --Dave Day ----- Original Message ----- From: "Peter Relson" <[email protected]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Sunday, January 01, 2012 10:23 AM Subject: Re: Question on adding an SVC routine dynamically to a running system > >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? > By "malicious" use I do mean that the SVC would be executed over and > over, but the overhead is irrelevant, as that is limited by the user's > priority and job class.. > It could conceivably cause the trace table to fill more than it should > and potentially wrap with the lost of serviceability data that goes > with such occurrence. That is my concern. > > I also have no idea what data you are tracing. Is it storage area(s) > identified by the caller? > >>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. > > Your SVC is not a BR R14. And even if it was, you are not the only one > who looks at dumps and no one else has any idea what your control > structures are. For example, a significant percentage of IBM's service > time is spent diagnosing situations that are not related to IBM code > and any clue that can help them is always appreciated. And the same is true > of customers. > Suppose someone (not you) has a dump and the system trace shows the > SVC and for some reason they feel this should be investigated, but the > SVC routine storage is not in the dump because the dump has (E)SQA but > not (E)CSA. It can surely be helpful to be able to answer the question > of "what module is this?" which might let them answer the question of > "who owns this module?". > > Peter Relson > z/OS Core Technology Design > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
