Ed Gould wrote:
While a overhaul is needed in some areas SMF processing of writing to
its own data sets has never been a "major" issue (that I have seen).
If this wasn't a real problem, Ed, we wouldn't have spent the money to
solve it. We have other things to work on, too. Perhaps you have lost
touch with this particular issue.
There have been one or two instances in the past where a program loop
would cause SMF processing to be delayed in writing of the data, I have
never heard of it as a "hot" issue (I don't recall of a GUIDE/SHARE
requirement).
I'm not sure it was ever a SHARE requirement. The problem is likely too
"new" to ever have been a GUIDE requirement. At some point, you can
overrun a recording technology and need to fix or replace it. Up until
that point, it works fine. We passed that point with SMF data volumes
on large busy systems, and had to do something about it.
I would think basic changes in the catalog structure and
or the ability to create tape files of more 255 volumes would be of
higher priority.
What catalog changes are you talking about?
So far as support for more than 255 tape volumes per data set goes, the
current JB/JX media support 700GB/tape. What data sets larger than
178.5 TB do you believe people need to create? (Just think of the time
it would take to create such a file at currently sustainable data rates!)
I know there is still a small shakeout of issues with
the console rewrite but overall no big buyback (I have seen).
Yeah, but watch this space.
I am sure
there are other hotspots that could be addressed that everybody would
see an immediate benefit. While the improved SMF processing is nice
(don't get me wrong) I am just wondering if its that big of a payback.
Speaking of revamping SMF records could be user of bigger buyback than
faster writing, IMHO.
If we revamped the SMF record formats we would break an awful lot of
vendor-, customer-, and IBM-written code. What value do you foresee
that would justify the mayhem we would cause by doing that?
This new facility is nice (don't get me wrong) and its reasonably
internal code only and probably won't make any difference to the users I
just think there could have been something given to help the "sell" Z/os
a little more to the pointy headed types.
On the contrary, I think this will make a significant difference to
those who need it. To those whose SMF data write rates remain
comfortably within the capacity of the ICIP recording technique used for
SYS1.MAN data sets, though, I agree it will make little difference in
the short term.
<snip>
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
----------------------------------------------------------------------
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
