*** Original Author: ADSM-L @ MARIST - ** Remote User **; 11/12/98 07:51am
>Received: from VM.MARIST.EDU by AUDUCADM.DUC.AUBURN.EDU (IBM MVS SMTP V3R1)
> with TCP; Thu, 12 Nov 98 07:51:03 CST
>Received: from VM.MARIST.EDU by VM.MARIST.EDU (IBM VM SMTP V2R3)
> with BSMTP id 2663; Thu, 12 Nov 98 08:44:22 EST
>Received: from VM.MARIST.EDU (NJE origin LISTSERV@MARIST) by VM.MARIST.EDU
> (LMail V1.2b/1.8b) with BSMTP id 1639; Thu, 12 Nov 1998 08:44:19 -0500
>Received: from VM.MARIST.EDU by VM.MARIST.EDU (LISTSERV release 1.8c) with NJE
> id 4613 for ADSM-L AT VM.MARIST DOT EDU; Thu, 12 Nov 1998 08:44:13
> -0500
>Received: from MARIST (NJE origin SMTP@MARIST) by VM.MARIST.EDU (LMail
> V1.2b/1.8b) with BSMTP id 1623; Thu, 12 Nov 1998 08:44:13 -0500
>Received: from smtp3.ny.us.ibm.com by VM.MARIST.EDU (IBM VM SMTP V2R3) with
> TCP; Thu, 12 Nov 98 08:44:12 EST
>Received: from relay2.server.ibm.com (relay2.server.ibm.com 9.14.2.99 ) by
> smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id IAA59924 for
> <ADSM-L AT VM.MARIST DOT EDU>; Thu, 12 Nov 1998 08:25:42 -0500
>Received: from US.IBM.COM (d03lms03.boulder.ibm.com 9.99.80.13 ) by
> relay2.server.ibm.com (8.8.7/8.8.7) with SMTP id IAA25810 for
> <ADSM-L AT VM.MARIST DOT EDU>; Thu, 12 Nov 1998 08:39:10 -0500
>Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D03AU018 id
> 5030300027408447; Thu, 12 Nov 1998 08:52:43 -0500
>MIME-Version: 1.0
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: quoted-printable
>Message-ID: <5030300027408447000002L072*@MHS>
>Date: Thu, 12 Nov 1998 08:52:43 -0500
>Reply-To: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>Sender: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>From: Bob La Brie <labrie AT US.IBM DOT COM>
>Subject: Re: OS/390 Server
>To: ADSM-L AT VM.MARIST DOT EDU
>
The MPTHREADING support on MVS can be used if you have Enterprise Manag=
ement
level code 3.1.2.0 applied. APAR PQ19265 (spin loop) can occur und=
er
certain conditions
and will be fixed in the next PTF. A fixtest for this problem is a=
vailable
on index.storsys.ibm.com.
We are still working through some of the performance issues with
MPTHREADING, however
the option reportedly provides some relief to migration and heavy=
BU/archive loads
where several hundred simultaneous sessions are moving data to a =
single
server.
Admin commands and central scheduling work can stack up behind cl=
ient work
during heavy client loading when MPTHREADING is not used.
Thanks, Bob La Brie ADSM Development
---------------------- Forwarded by Bob La Brie/Tucson/IBM on 11/12/98 =
06:20 AM
06:20 AM
---------------------------
ADSM-L AT VM.MARIST DOT EDU on 11/11/98 11:43:58 PM
ADSM-L AT VM.MARIST DOT EDU on 11/11/98 11:43:58 PM
Please respond to Andreas.Buser AT basler DOT ch
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: OS/390 Server
Hi Christo,
we run our ADSM Server on a R54 and I am thinking about using
MPTHREADING Yes.
You say, ADSM used all your CPU.
Did you have WLM to keep ADSM on an reasonable level if cpu usage is to=
high?
Normaly WLM does a good job in managing cpu-burners like ADSM or HSM.
------------------------------------------
Kind Regards
Kind Regards
Andreas Buser
Tel: ++41 61 285 73 21 Fax: ++41 61 285 70 70
Email: Andreas.Buser AT Basler DOT ch
Address:
Basler Versicherungsgesellschaft
Andreas Buser
Abt. Informatik
Aeschengraben 21
4002 Basel
Switzerland
=
*** Comments From: STEWAJM - Stewart, Mike; 11/12/98 09:40am
I run with MPThreading Yes on my MVS server.
Otherwise some of the admin processes seem to lock the server up
and prevent client access for potentially long periods of time.
ADSM doesn't seem to use much more CPU with MPThreading YES
then without, that I can tell.
As far as MPThreading allowing ADSM to use multiple processors,
I also haven't seen ADSM go much beyond
1 sec of cpu/1 sec clock time. On our R42 (4 processors)
I would have expected as much as 4 sec of cpu/1 sec clock time
if it was using all four processors.
So the option didn't seem to provide alot of increased capacity
but definately keeps one process from
monopolising the server.
|
