Guessing once again, if for "offending" you mean jobs using lot of CPU within one interval, it's better to look at SMF30 subtype other than 4 (2,3, or 6 maybe).
Usually this "prunes" problems like jobs waiting for init or HSM recall and so on and gives you a good understanding about ASs using more CPU. With SMFINTVL little (reasonably) enough it can be a good point view. Regards. Massimo 2017-04-10 10:48 GMT+02:00 Lindy Mayfield <[email protected]>: > My question I guess was a bit more theoretical. > > If I submitted an assembler job that ran in a tight loop doing nothing but > using CPU, it went straight into the RDR, high service class, and ran for > 10 CPU seconds. > > I'd expect the job to run at least 10 seconds wall clock time, plus the > overhead of the system, but never under 10 seconds unless it is > multithreaded perhaps. > > From SMF recs I can identify jobs sorted on cpu and excp to try to get the > worst offenders in all cases, but then I have to go into the individual job > log and see elapsed time. I have already discovered huge wait times that I > cannot explain due to what I think is taking 20 minutes to not find a > dataset, perhaps some sort of catalog search problem. > > So, as Lizette pointed out, my scheme has flaws because there are too many > factors that influence elapsed time, including locating system issues from > RMF3 and other nasty SMF record types. It's easier to write a program to > parse the job logs. :) > > Thanks for all you help and knowledge. I joined this group about 17 years > ago, and I'm still the baby of the group. :) > > /Lindy > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Lizette Koehler > Sent: sunnuntai 9. huhtikuuta 2017 22.16 > To: [email protected] > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > > I am not sure that looking at one SMF record can tell the story. > > If the job ran long, was it due to > > I/O > > Looping Code > > Larger than normal Data Load > > And so on. > > Maybe other can provide better insight. > > Lizette > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] > > On Behalf Of Lindy Mayfield > > Sent: Sunday, April 09, 2017 9:42 AM > > To: [email protected] > > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > > > > I only have CPU time from SMF 30 but I don't have elapsed time which > > is very important. I'd like to somewhat infer that a high CPU time > > means the job ran a long time. > > > > /Lindy > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] > > On Behalf Of Lizette Koehler > > Sent: sunnuntai 9. huhtikuuta 2017 18.55 > > To: [email protected] > > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > > > > What are you trying to solve? > > > > Jobs get swapped in and out depending on what work they are doing. > > > > > > Are you trying to relate wall clock to cpu time? I have seen jobs run > > 2 hours wall clock time and only take 10 mins of CPU time. > > > > Lizette > > > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List > > > [mailto:[email protected]] On Behalf Of Lindy Mayfield > > > Sent: Sunday, April 09, 2017 8:48 AM > > > To: [email protected] > > > Subject: CPU Timerons/Seconds vs Wall-clock Time > > > > > > This may or may not be the dumbest question I've asked this week, > > > but I've been working with Linux a lot lately so that's my excuse. > > > > > > For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I > > > think), can I assume that it at least took 10 seconds of elapsed > > > time to > > run? > > > > > > Regards, > > > Lindy > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
