I say Sam is correct but there are some assumptions being made. The staff is at a high enough level of expertise that problems do not accumulate in the technical software. The application staff is at a high enough level of expertise to fix their applications as opposed to requiring technical software to mask or recover errors due to defective applications. Scalability is not inherint in z/OS, it requires simplificaton and standardization which is a function of the design of the configuration of z/OS, which is the responsibility of the z/OS sytem programmer. The measure of a configuration is not only that it is error-free, but that is remains error-free during the changes that are required. If change is allowed to introduce random complexity or pathological coupling in the name of expediency, I would expect a decrease in reliability and/or the need for an increase in staff. Another factor to consider is that if the current staff is 80% occupied with resolving problems, additional staff will be required to achieve standardization. Another factor to consider is the level of cooperation with the stated goals, demonstrated by meeting standardization milestones. If the time to achieve standardization is delayed by excuses or failure to institutionalize the standardization goal into the professional evaluation process, staff requirements will be dramatically increased. * I am going to leave off this so I do not go into a thesis on recognizing sabotage behaviour of IT managers. *
On Fri, Sep 5, 2008 at 7:15 AM, Knutson, Sam <[EMAIL PROTECTED]> wrote: > It is not a linear function on System z. > Scalability is part of the value proposition for the platform not just > for the machines but people's ability to manage them. > That is not just marketing from IBM. We have doubled MIPS with > negligible staff growth for the platform. The sticky part is that is > that it takes a certain critical mass to support 24x7x365 operation of > z/OS + transaction subsystems + middleware. Once you have that core > staffing level you can run nn more LPARS with nnnnn more MIPS without > any additional systems programming staff. > > Best Regards, > > Sam Knutson, GEICO > System z Performance and Availability Management > mailto:[EMAIL PROTECTED] > (office) 301.986.3574 > > "Think big, act bold, start simple, grow fast..." > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Nagaraj_Pudukotai > Sent: Friday, September 05, 2008 7:56 AM > To: [email protected] > Subject: Number of Sysprogs & sysadmins per 100 MIPS > > Dear List > > I am in search of information on typically how many system programmers > and system administrators would be required, on an average, to support > say 100 MIPS. It is not that I am specifically looking at 100 MIPS > installation, but rather I want to extrapolate this number (if possible > linearly) to estimate the number of sysprogs and sysadmins required to > support a site of any size - say X MIPS. I know the number of sysprogs > and sysadmins at different sites varies even when comparing sites of the > same size. Nevertheless I am looking for a rough ballpark number. > > I also understand this number is a function of the subsystems installed > at a site. For e.g. x number of DB2 sysprogs & x' sysadmins + y number > of IMS sysprogs & y' sysadmins + z number of CICS sysprogs & z' > sysadmins etc. > > So what I am after is - on an average how many sysprogs + sysadmins > (z/OS, DB2, CICS and IMS) are typically required to support on an > average say 100 MIPS? > > > Thank you in advance. > > Nagaraj > > > > > ________________________________ > DISCLAIMER: > This email (including any attachments) is intended for the sole use of > the intended recipient/s and may contain material that is CONFIDENTIAL > AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or > copying or distribution or forwarding of any or all of the contents in > this message is STRICTLY PROHIBITED. If you are not the intended > recipient, please contact the sender by email and delete all copies; > your cooperation in this regard is appreciated. > > ---------------------------------------------------------------------- > 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 > > ==================== > This email/fax message is for the sole use of the intended > recipient(s) and may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution of this > email/fax is prohibited. If you are not the intended recipient, please > destroy all paper and electronic copies of the original message. > > ---------------------------------------------------------------------- > 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 > > -- Glen J. Gasior (630) 712-2104 Chicago, Illinois 60611 "Leadership that improves the process of change" ---------------------------------------------------------------------- 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
