SMF Records recording

Dear folks; As a possibly a neverending debate, I wanto to know, besides storage and CPU usage implications, what are the benefits of not having all the smf records ON with the exception of 4,5 and 99. I don't have neither the VSAM SMF records ON nor the CICS record ON. I run about 10k+ Jobs

Re: SMF Records recording

Records recording Dear folks; As a possibly a neverending debate, I wanto to know, besides storage and CPU usage implications, what are the benefits of not having all the smf records ON with the exception of 4,5 and 99. I don't have neither the VSAM SMF records ON nor the CICS record ON. I run

Re: SMF Records recording

Giovanni Cerquone wrote: Dear folks; As a possibly a neverending debate, I wanto to know, besides storage and CPU usage implications, what are the benefits of not having all the smf records ON with the exception of 4,5 and 99. I don't have neither the VSAM SMF records ON nor the CICS record

Re: SMF Records recording

On Mon, 7 Aug 2006 18:53:32 -0400, Knutson, Sam <[EMAIL PROTECTED]> wrote: >I do record type 99 records and retain them for 5 days. >I needed them once and it was worth having them when IBM asked for them. > How long ago was that? They are always there in a WLM asid buffer if you don't record th

Re: SMF Records recording

On Tue, 8 Aug 2006 11:09:27 +0200, R.S. <[EMAIL PROTECTED]> wrote: BTW: Cost >of offload jobs is rather irrelevant, beacuse usually they don't burn >CPU cycles during "rush hours". > No, they burn cycles whenever a dump is triggered by a MAN dataset filling up. Yes, in some small shops / enviro

Re: SMF Records recording

Mark; Another debate is what's small and what's large. I'm a 303&304 complex and I do not condider myself large. I have one (1) man dataset per 3390-9 volume and each is dumped four times a day and I don't have VSAM nor CICS activity logged. I prefer to have all the possible records rather tha

Re: SMF Records recording

On Tue, 8 Aug 2006 09:29:32 -0500, Giovanni Cerquone <[EMAIL PROTECTED]> wrote: >Another debate is what's small and what's large. I'm a 303&304 complex and >I do not condider myself large. Too hard to debate that... it's always relative. Someone on a small z800 might think you are a large sho

Re: SMF Records recording

Thanks so much to all responders and Mark, as always, very proficiency. Giovanni -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the ar

Re: SMF Records recording

>I don't have VSAM nor CICS activity logged. Yes, you do. You just don't have the records written to SMF. Most activity is monitored all the time. When in doubt. PANIC!! -- For IBM-MAIN subscribe / signoff / archive access

Re: SMF Records recording

>40s (dynamic DD) are also in the 30s, so they are excluded as well But, IIRC, the 40's have dataset names. I know the 30's have only DDNames. When in doubt. PANIC!! -- For IBM-MAIN subscribe / signoff / archive access instr

Re: SMF Records recording

On Tue, 8 Aug 2006 20:58:44 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >>40s (dynamic DD) are also in the 30s, so they are >excluded as well > >But, IIRC, the 40's have dataset names. >I know the 30's have only DDNames. > >When in doubt. >PANIC!! > How 'bout "when in doubt, RTFM". :-) I don'

Re: SMF Records recording

>How 'bout "when in doubt, RTFM". :-) Unlike others, I am willing to admit I was wrong. The local Montanna's doesn't seem to have a Funny Manual available. I was going by (obviously shaky) memory. They say the mind is the second thing to go. I'll be diddly dadburned if I can recall what the fi

Re: SMF Records recording

On Tue, 8 Aug 2006 21:18:21 +, Ted MacNEIL wrote: >I was going by (obviously shaky) memory. Ted, Were you thinking of the SMF Type 42 records, maybe? One of its subtypes (subtype 6) has dataset names and oodles of tuning/performance information. (I've always been a fan of T42-6.) --

Re: SMF Records recording

>Were you thinking of the SMF Type 42 records, maybe? >One of its subtypes (subtype 6) has dataset names and oodles of >tuning/performance information. >(I've always been a fan of T42-6.) Got it in one! Now that our shop has MXG again, I am going to be paying with all the DSN records. When in

Re: SMF Records recording

In <[EMAIL PROTECTED]>, on 08/07/2006 at 05:40 PM, Giovanni Cerquone <[EMAIL PROTECTED]> said: >As a possibly a neverending debate, I wanto to know, besides storage >and CPU usage implications, what are the benefits of not having all >the smf records ON with the exception of 4,5 and 99. The

Re: SMF Records recording

In <[EMAIL PROTECTED]>, on 08/08/2006 at 08:58 PM, Ted MacNEIL <[EMAIL PROTECTED]> said: >But, IIRC, the 40's have dataset names. You don't. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see We don't care. We don't have

Re: SMF Records recording

Mark Zelden wrote: On Tue, 8 Aug 2006 11:09:27 +0200, R.S. <[EMAIL PROTECTED]> wrote: BTW: Cost of offload jobs is rather irrelevant, beacuse usually they don't burn CPU cycles during "rush hours". No, they burn cycles whenever a dump is triggered by a MAN dataset filling up. Yes, in som

Re: SMF Records recording

> No, they burn cycles whenever a dump is triggered by a MAN dataset > filling up. Yes, in some small shops / environments you can have > enough of them and only dump them all once a day. That doesn't > work in larger environments. I have never seen SMF Dumps 'burn' cycles. Make them low import

Re: SMF Records recording

On Sun, 20 Aug 2006 18:58:23 +0200, R.S. <[EMAIL PROTECTED]> wrote: >Mark Zelden wrote: >> On Tue, 8 Aug 2006 11:09:27 +0200, R.S. <[EMAIL PROTECTED]> wrote: >> >> BTW: Cost >> >>>of offload jobs is rather irrelevant, beacuse usually they don't burn >>>CPU cycles during "rush hours". >> >> No, th

Re: SMF Records recording

On Sun, 20 Aug 2006 17:07:37 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >> No, they burn cycles whenever a dump is triggered by a MAN dataset >> filling up. Yes, in some small shops / environments you can have >> enough of them and only dump them all once a day. That doesn't >> work in larger

Re: SMF Records recording

>I can just say in _my_ experience, one way doesn't work well in a large shop. Define "LARGE". I have been in the 3500-4000 MIPS/10-14 TB range for the last few years. When in doubt. PANIC!! -- For IBM-MAIN subscribe / sign

Re: SMF Records recording

On Mon, 21 Aug 2006 18:21:16 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >>I can just say in _my_ experience, one way doesn't work well in a large shop. > >Define "LARGE". > >I have been in the 3500-4000 MIPS/10-14 TB range for the last few years. > I'm happy defining "n" number of SMF dsn's an

Re: SMF Records recording

>I'm happy defining "n" number of SMF dsn's and dumping SMF once a day worked >for you - congratulations. I never said that. What I said was that you should have enough so that when you slow down your dumps, you don't lose data. At a bank I used to work at the CICS/DB2 processor dumped every 2