Hi Matt,

we decided to have many small databases.
thats why we have 10 TSM-Server.
If we have to reorganize one of our database, we only have to shut down one 
TSM-Server.
And we dont have one big server reorganizing or auditing for weeks ;)


-- 
regards / Mit freundlichen Gruessen
regards / Mit freundlichen Gruessen
Joachim Stumpf
Datev eG
Nuremberg - Germany
      

"MC Matt Cooper (2838)" <Matt.Cooper AT AMGREETINGS DOT COM> (Mittwoch, 20. 
März 2002, 15:20:52, CET):

> At what point does it make sense to split your TSM address space?  I have a
> 28GB 80% utilized DB  using TSM 4.1.5 on a     9672-x57 that is running
> O.K..   I know the DB is going to grow because the TSM requirements are
> growing.   Where should I expect to see problems?
> 
> 
> Christo,
> If your TSM on OS390 is spending all its time doing GETMAIN/FREEMAIN what is
> your REGION size and available memory?  Is the system paging or is TSM
> trying to live in to small of an address space?
> Matt
> 
> -----Original Message-----
> From: Stumpf, Joachim [mailto:joachim.stumpf AT DATEV DOT DE]
> Sent: Wednesday, March 20, 2002 7:27 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: People running OS/390 TSM servers - maybe for the development
> guys......
> 
> Hi Christo,
> 
> we are running TSM-Server 4.1.5 on OS/390.
> Im not very familiar with this OS/390- MVS- Stuff, but I can tell you that
> we have 10 TSM-Server running at 1 LPAR.
> We named the tasks TADSM01-TADSM10.
> The issue to do so was that we only wanted small databases.
> Now our dbs are from 7GB - 12GB.
> 
> --
> regards / Mit freundlichen Gruessen
> Joachim Stumpf
> Datev eG
> Nuremberg - Germany
>      
> 
> Christo Heuer <christoh AT ABSA.CO DOT ZA> (Mittwoch, 20. März 2002, 11:55:08,
> CET):
> 
> > 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."
> >
>