Christo,

I have had hi CPU problems in the past.  I took svc dumps and reported
it to tsm.  Level 2 confirmed that the dump showed lots of activity in
getmain & freemain.  They said tsm should not be doing any getmains or
freemains unless it runs out of it preformatted cellpools.  The size of
the preformatted area is a small percentage of the region in the JCL.
I was running with region=0m; for some forgotten reason I thought that was the 
right
thing to do.  Level 2 said to change it to a real value; I set it to 512m
and the server has behaved better ever since.

But there are still hi CPU problems now and then, they seem to occur after the
server has been running a long time.  Just last week I set up automation to
restart the server on Sunday.

Hope this helps,

Bill Colwell
C. S. Draper Lab
Cambridge Ma.



At 12:55 PM 3/20/2002 +0200, you wrote:
>Hi all,
>
>OK - For those of you that does not know anything about
>OS/390 or don't run TSM servers on OS/390 this might be
>very boring and maybe a bit cryptic - ignore or just
>read for the fun.
>Now for the people that still run OS/390 TSM servers:
>
>I have always had my doubts about the scalability of
>OS/390 when it comes to a TSM server.
>Some of you might have seen me posting last year and early
>this year about the size of your TSM environment and if
>you are happy with the performance of TSM on OS/390 - only
>one guy answered giving me specs on the environment they
>run(Thanks to William Colwell), but other than that
>most people said they moved off OS/390 and are now
>running AIX or Sun or even Win2K servers.
>William described their environment as an 80 Mips
>processor box and a 166Gig db 88% used - and on top
>of all that he has good performance from this.
>
>Our environment is a 38 Gig db 80% used and we have
>crappy performance. Now in Adsm V3 a new parameter
>was introduced called MPTHREADING YES or NO. What
>this does is tell TSM that it can start multiple
>TCB's on multiple CP's - if you have multiple CP's
>on your box.
>Now we enabled this and noticed that TSM gets its
>knickers in a knot when there are too many things
>happening and the system is CPU constrained. In
>WLM it is guarenteed to get CPU and in WDM you can
>see that about 30% of the time it is delayed for
>CPU. What we have done now in Omegamon is to check
>how many work each of the TCB's does and then try
>and figure out why TSM would perform crappy even though
>it is getting about 50% of the total box.
>Now - here comes the part where development might
>be able to shed some light:
>
>The TCB called dsmserv (the server task), has a
>lmod caled IEANUC01 that has a CSECT of IGVGPVT
>that uses about 90-95% of all the CPU cycles - remember
>that this is one TCB assigned to one CP.
>On further investigation our IBM'er came back and said
>this IGVGPVT part controls getmain/freemain's for TSM.
>Now here comes the question:
>How can TSM be using 90% of a CP by just doing getmain/freemain
>and all the other TCB's that has a CP allocated just sit
>and wait for getmain/freemain's. This looks like a
>serious scalability issue with TSM on a multiple
>CP environment. According to our performance and MVS
>guys the only way we are going to squeeze more juice
>out of our OS/390 system with TSM is to split the
>workload of TSM and run two TSM servers on one LPAR
>or upgrade each CP to a more powerfull CP.
>Is this in line with development, and the way it should work?
>
>Thanks
>Christo Heuer
>ASBA Bank
>Johannesburg
>SOUTH AFRICA
>______________________________________________
>"The information contained in this communication is confidential and
>may be legally privileged.  It is intended solely for the use of the
>individual or entity to whom it is addressed and others authorised to
>receive it.  If you are not the intended recipient you are hereby
>notified that any disclosure, copying, distribution or taking action
>in reliance of the contents of this information is strictly prohibited
>and may be unlawful.  Absa is neither liable for the proper, complete
>transmission of the information contained in this communication, any
>delay in its receipt or that the mail is virus-free."

----------
=========================================================================