---------------------------------------<snip>--------------------------------------
Does the presentation shows CI size and BUFSPACE of MANx datasets ?
---------------------------------------<unsnip>------------------------------------
AFAIK, it does not. SMF is more than adept at managing the space and the
selection of CI size during definition of the cluster(s) seems to be
pretty optimal as is, without a human "second guess" cluttering up the
picture.
I've found that with only a few extreme exceptions, the best CI size is
usually "automagically" assigned during IDCAMS definition/allocation
processing.
Rick
-----------------------------------------------------------------------------------------
Atenciosamente / Regards / Saludos
Ituriel do Nascimento Neto
BANCO BRADESCO S.A.
4254 / DPCD Engenharia de Software
Sistemas Operacionais Mainframes
Tel: +55 11 4197-2021 R: 22021
Fax: +55 11 4197-2814
-----Mensagem original-----
De: IBM Mainframe Discussion List [mailto:[email protected]] Em nome de Mark
Zelden
Enviada em: quinta-feira, 22 de setembro de 2011 13:53
Para: [email protected]
Assunto: Re: How to dumps all the SMF datasets automagically evertime
On Thu, 22 Sep 2011 08:43:55 -0700, Ed Gould <[email protected]> wrote:
(btw, below is what I see from the archives - all the #39 stuff instead of
single quotes)
Sam,
Good suggestion. I haven't seen any data as to performance though. In the past
dumping SMF was while not slow it wasn't
fast either. Has IBM ever been able to speed it up? The log stream might just
be the answer to my issue, has onyone come up with any
numbers?
Of course there have been numbers published by IBM and "speeding up" was
one of the main reasons this was done.
Here is a data and some verbiage from a SHARE presentation (session
2853, I think it was San Jose). View in fixed font...
---------+----------+----------+----------+----------+----------+
|Base run |Using 1 |split |mult |Mult+ dup |
|with manx |log |across 3 |streams + |30 and |
|dsns |stream |logstreams|dup typ30 |100:102 |
---------+----------+----------+----------+----------+----------+
CPU% | 86.56% | 86.19% | 87.05% | 86.34% | 86.95% |
---------+----------+----------+----------+----------+----------+
TOT DASD | | | | | |
I/O rate | 4643 | 3622 | 3387 | 3436 | 3256 |
---------+----------+----------+----------+----------+----------+
SMFLOGR | | | | | |
# of REQ | | 82769 | 90474 | 91879 | 149324 |
---------+----------+----------+----------+----------+----------+
SMF data | | | | | |
log rate | 17355.19 | 17010.23 | 17221.54 | 17199.62 | 34472.71 |
(rec/sec)| | | | | |
---------+----------+----------+----------+----------+----------+
SMF avg | | | | | |
rec len | 298.12 | 298.12 | 298.12 | 298.12 | 298.3 |
---------+----------+----------+----------+----------+----------+
SMF size | | | | | |
in MB | 1776.33 | 1741.02 | 1762.65 | 1760.40 | 3530.46 |
---------+----------+----------+----------+----------+----------+
Here we see some interesting comparisons between SMF recording
to MANx data sets versus log streams.
1) When using the same workload, log stream recording did not
cause any significant change in CPU utilization. Compared to the
work load itself, SMF was not a significant contributer.
2) The DASD I/O rate, however, was lower when using log streams.
System Logger creates larger write requests than SMF recording
to MANx data sets, resulting in greater efficiency in I/O.
3) Even when duplicating records to multiple log streams, the
effect of SMF recording was insignificant compared to the
workload.
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:[email protected]
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
----------------------------------------------------------------------
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
AVISO LEGAL <br>...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação.
LEGAL ADVICE<br>...This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void.
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
