[EMAIL PROTECTED] wrote:
Binyamin Dissen wrote:
On Thu, 21 Jun 2007 15:54:09 +0000 Ted MacNEIL <[EMAIL PROTECTED]>
wrote:
:>>ever have "users" cruise your parmlib and then tell you how to tune
the system? Solution: >UACC(NONE).
:>I have yet to see a single member of PARMLIB that is any business of
anybody outside SYSPROGs.
How much of PARMLIB cannot be detected by examining storage in a live
system -
not using APF or anything special?
Security by obscurity is useless.>>
100% agreed. However in this case UACC(N) not for security, it is for
shutting up folks commenting PARMLIB settings. Just to stop discussions
and complaints. IMHO, if I have nothing to be ashamed, I don't have to
hide it.
From the other hand it is not bad to hide PARMLIB, *but not for the
purpose above*.
Funny how it's ok for SYSPROGs to cruise Applications and "tell" us what
needs to be changed or how to tune our application (when we didn't ask
for their opinion), but it's not ok for us to cruise your PARMLIB
settings ???? Never heard of a PARMLIB setting getting screwed-up by
looking at it. Unbelieveable !!
...
> Tom Savor
...
Perhaps it's somehow related to the fact that most SYSPROGs have System
Performance as part of their job responsibility and training while
application folks only have responsibility that their apps generate
correct results in a manner their end users find acceptable. If their
apps cause system-wide problems to other end-users, that's frequently
viewed as someone else's problem.
As a SYSPROG I have never had time to randomly inspect application code,
but if the system is under stress, one starts looking for what changed
and if there are any obvious big resource hogs contributing to the
problem. If this points to application code, then we do whatever it
takes to resolve the problem, and if this involves looking at
application code or JCL for obvious deficiencies, we go to that level.
The more experienced application programmers usually do a decent job,
but we also find that most colleges tend to do a poor job of instilling
performance thinking into new programmers - the idea that techniques OK
for 100 transactions may be inappropriate when scaled to millions, or
that dataset access can be tuned for performance, too often tends to be
untaught or unlearned. Fortunately, everyone here accepts that
eliminating performance problems is part of our job and theirs.
We publish daily charts and tables of where the system resources are
being used. We have on numerous occasions had application areas and
managers question relative allocation of resources when their users are
hurting and request changes to policies and/or priorities. The esoteric
details of how such changes are implemented, via PARMLIB or elsewhere,
is generally of minimal interest - their interest is in the results.
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
