IBM Mainframe Forum

You are posing good questions, and I don't have easy answers to them, though I rather doubt SRB code could be used to answer these questions.

You are correct when you say TIMEUSED probably won't answer questions about resource usage for database calls, though I'm not so sure an SRB function can expose this information without very deep knowledge about how the database processor works internally, knowledge which I'm not certain IBM has divulged. SRB usage can be interpreted at many different levels, but one should be extremely careful about this interpretation. One possible use of an SRB function in a database application is that it can be used to communicate the result of a database function back to the requester.

When I did my SRB code almost 30 years ago it was to, in part, do the kinds of performance analysis you are curious about, but the target was in source, so the deep knowledge of its functioning could be easily acquired. Sadly, most database systems are OCO, so it will be much more difficult for a user (us, in other words) without access to the source to acquire this knowledge.

Reviewing the intelligence gathered using my code, I think the only useful point we extracted was resisted by the product vendor. This was something that was inserted relatively late in development; the SRB code was able to detect when the object being analyzed was stuck on a page fault, and we located a single point where there were a lot of avoidable page faults to extract just a couple of data bytes that could be stashed in a more heavily used storage area, one unlikely to get a repeated page fault, shortly after the application obtained the page containing the data rather than many minutes later after the page had been sent off to the page dataset. I was convinced that other data acquired by the SRB code was misunderstood, and, so, misused. Other data obtained by the code didn't reveal much that was a surprise. The largest CPU user was EXCP, which was no surprise. Code that was thought to be a significant CPU user turned out not to be, which was a bit of a surprise. While it was possible to make minor improvements in other code, the EXCP hammer head, which we could do nothing about, made any net improvement we could do elsewhere nearly pointless.

The target had little direct involvement with user code, and my SRB code did not measure this involvement. Indeed, it could not measure this involvement, since it would have to interrogate user address spaces, which would have greatly increased its overhead and risks, both in the SRB code and its driver that issued the SCHEDULE macro to start the SRB code.

I'm not sure SRB code could track a database function back to a user request, which I'm thinking is one of your goals, though it might be possible.

One weakness in my approach is the targeted application ran a number of subtasks, and we made no attempt to measure subtask usage, something that I now think would have been useful.

See section 9.2 of the Authorized Assembler Services Guide manual, which describes the situations where an SRB is useful.

Most of the time, the SMF data is the most useful for performance measurement and analysis as it represents the system as a whole. It sounds like you're wanting to do dynamic performance analysis while a program is running, which is rarely (if ever) a good idea. If your site uses MXG or MICS, your best source of performance data is those products.

Robert Sample wrote:See section 9.2 of the Authorized Assembler Services Guide manual, which describes the situations where an SRB is useful.

Most of the time, the SMF data is the most useful for performance measurement and analysis as it represents the system as a whole. It sounds like you're wanting to do dynamic performance analysis while a program is running, which is rarely (if ever) a good idea. If your site uses MXG or MICS, your best source of performance data is those products.

SMF (and MXG or MICS) is useful at a global level, but it is not so good analyzing things at a microscopic level, and your reference directly states that is something an SRB should be used for. See the "To account for resources" bullet.

I am not saying the SRB is not an appropriate tool, though it may be beyond the original poster's expertise.

Heck, it was probably beyond my level of expertise almost 30 years ago when I wrote a fairly large SRB routine. I know there were bugs in it; other people got it and fixed them, as well as made some improvements in both the SRB code, the code that did the SCHEDULE, and the final reporting code which was separate from the data gathering code.

To get to current PSW, I will use the CB (Control Blocks).
Where I will map the EPIE, and get the EPIEPSW.
and thats it.

belkin99 wrote:To get to current PSW, I will use the CB (Control Blocks).
Where I will map the EPIE, and get the EPIEPSW.
and thats it.

Have YOU ever done this?

DB2 charges the CPU time back to the caller's TCB, so I would imagine that TIMEUSED would work in this instance. I can't comment on other DBMSs.

It really depends on whether you are looking at this for general interest, or if you have a real performance problem to solve. If it is the latter, I would suggest that the most expedient and cost-effective method would be to use a performance tool.

This isn't a plug for any particular product; the point I'm trying to make is that you need to be solving the problem rather than writing monitoring code. It would take you years to write anything even half as good as a commercial product.

TO STEVE-MYERS

YES i DID THAT, and I can send you the code

Hello,

Possibly this is only a small bit of code that could be posted in this topic?

d

Sorry, whats thats suppose to mean???

Well, it is supposed to mean Exactly what it says.

I'll try to break it down for you. . .

"possibly" - might or might not be.
"small bit of code" - code that is only a few lines rather than several thousand.
"could be posted in this topic" - viewed on some terminal and then put into a reply using copy/paste and the Code Tag.

Just curious, but what part of that reply was not clear to you. . .

d