ED, I've have never observed SRB time to vary so much across MVS versions and releases, but I started with MVS/XA, Things may have been different in earlier versions. However, if the address space is burning the SRB CPU time then the user must still be responsible for the cost. If you ignore SRB time all you will do is adjust the charge for TCB time to account for a larger uncaptured, and some other application will be funding the SRB time of the IO intensive applications.
The same variability can happen in TCB time, but you don't suggest ignoring this. In fact I've observed this in the G4 when IBM put the compression instructions into macrocode and the CPU time for jobs using SMS compression went through the roof. It did not come down again until the G6. This was a variation in CPU time of 100s of percent. Your example for SRB time suggests that this is a basis for ignoring TCB time. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Ed Gould > Sent: Thursday, January 24, 2008 5:03 AM > To: [email protected] > Subject: Re: [IBM-MAIN] Accounting for SRB time > > On Jan 24, 2008, at 2:11 AM, Ron Hawkins wrote: > > > Ed, > > > > Seeing as captured SRB time is attributed directly to the address > > the owning > > address space, why wouldn't you include SRB time in your billing. > > In fact > > CPU Time for billing nowadays usually includes IO interrupt time, > > RCT Time > > (swapping) and Hyperspace access. > > > > I believe IBM has stayed with the original requirement for accounting > > records in z/OS and it's ancestors, that is if there is any > > ambiguity about > > the ownership of CPU time then ignore it, otherwise record it. > > That's why we > > have uncaptured. > > > > > > Ron > > -----------------SNIP---------------------- > > Because it is ever changing. If you (example) charge you users for > say copying a tape and say in rel 3.8 the SRB time is 20 secs and say > in rel 3.8 the time is increased to 25 sec but in say 1.3 it goes > down to 10 sec and you upgrade to 1.8 it changes *again* in 2.1 to > 25 secs . (and so on) (assuming the same amount of records) their > billing is changeable and the user comes to you and asks why am I > getting charged say 2.50 back in 3.8 and now I am getting hit with > 3.50 (these are JUST examples don't get hung up on specifics I am > just pointing out variables that can happen) its difficult (to me) to > explain that at one time it didn't cost as much to do the same amount > of work as it does today (don't even try and talk about inflation > etc) he can see the timing of SRB has changed. > > And how can the user budget for such changes as tomorrow the same job > might increase to say $5.00 When he is getting no more work done that > it costs say 6 months ago. I know I am not using real numbers but as > a typical user would say "why?". The money is as I said a simple > example not a real life one as I don't have a report in front of me. > Of course if you are recalling a dataset off a tape and your friendly > dasd back up package as more gets on a tape it has to spin further > into a tape one day that say 6 months from now that time can also be > a complicating issue and the amount of time you have to do to > investigate this does mount up and then how do you charge that time > of research? I have seen users challenge practically every charge and > it gets time consuming for the research. I have latterly seen a weeks > worth of research done over $1000. (us). And, it really gets ugly at > the end of the financial year the number of hours gets really high. > > Division can't budget if their work doesn't change. Now granted you > can always charge more but then the users get upset, they do want > consistency for budget purposes. > > Ed > > ---------------------------------------------------------------------- > 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
