Then, the easiest way to guarantee N jobs running concurrently is going
back to JES2 managed jobclasses and start N initiators. The N jobs will
run, but not necessaraly perform. But if that's what they want...
Kees.
""??? ?? ???"" wrote in message
news:...
> Believ
בי
Sender: IBM Mainframe Discussion List
Date: Tue, 12 Jul 2011 16:23:38
To:
Reply-To: IBM Mainframe Discussion List
Subject: Re: Managing WLM manged initiators
Believe me, we've tried, but they 'know best'
-Original Message-
From: IBM Mainframe Discussion List [mailto
Believe me, we've tried, but they 'know best'
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Ted MacNEIL
Sent: Tuesday, July 12, 2011 4:16 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Managing WLM manged initiators
>Bec
>Because sometimes the client says that they want to see n number of jobs in a
>certain class running.
>We know that it might not be the best thing, but the client is always right.
You need to convince them (if you can) that performance experts know better.
Having more jobs in a class than the WL
, CP - SPLXM
Sent: Tuesday, July 12, 2011 3:15 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Managing WLM manged initiators
Gadi,
Then the question comes up: why do you want to change those values? You will be
manually interfering in the WLM algorithmes to manage your batch and the
systems in the
er SDSF or SYSVIEW.
>
> Gadi
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Lizette Koehler
> Sent: Tuesday, July 12, 2011 2:28 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Managing WLM manged initiat
Lizette Koehler
Sent: Tuesday, July 12, 2011 2:28 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Managing WLM manged initiators
> Yes, SDSF is a utility, but it doesn't do everything I am looking for.
>
> Gadi
>
> >Hi,
> >
> >We've started using WLM managed initi
> Yes, SDSF is a utility, but it doesn't do everything I am looking for.
>
> Gadi
>
> >Hi,
> >
> >We've started using WLM managed initiators.
> >
> >Using JES2 commands we can specify the maximum number of initiators per
class,
> and even
initiators
On Mon, 11 Jul 2011 12:44:09 +0300, גדי בן
אבי wrote:
>Hi,
>
>We’ve started using WLM managed initiators.
>
>Using JES2 commands we can specify the maximum number of initiators per class,
>and even per system.
>The number of jobs per system is visible and changeable
On Mon, 11 Jul 2011 12:44:09 +0300, גדי בן
אבי wrote:
>Hi,
>
>Weve started using WLM managed initiators.
>
>Using JES2 commands we can specify the maximum number of initiators per class,
>and even per system.
>The number of jobs per system is visible and changeable using
> I am looking for something I can show the operators.
> CA-SYSVIEW doesn't have it.
>
> Gadi
> >
> > Using JES2 commands we can specify the maximum number of initiators
> > per
> class, and even per system.
> > The number of jobs per system is v
g WLM manged initiators
>
> Using JES2 commands we can specify the maximum number of initiators
> per
class, and even per system.
> The number of jobs per system is visible and changeable using the JC
command.
> Does anyone know of a utility that can display and change the
>
> Using JES2 commands we can specify the maximum number of initiators per
class, and even per system.
> The number of jobs per system is visible and changeable using the JC
command.
> Does anyone know of a utility that can display and change the values per
system?
>>
> Th
WLM manged initiators
""??? ?? ???"" wrote in message
news:...
> Hi,
>
> We've started using WLM managed initiators.
>
> Using JES2 commands we can specify the maximum number of initiators
per class, and even per system.
> The number of jobs per system is visib
""??? ?? ???"" wrote in message
news:...
> Hi,
>
> We've started using WLM managed initiators.
>
> Using JES2 commands we can specify the maximum number of initiators
per class, and even per system.
> The number of jobs per system is visible and cha
Hi,
We’ve started using WLM managed initiators.
Using JES2 commands we can specify the maximum number of initiators per class,
and even per system.
The number of jobs per system is visible and changeable using the JC command.
Does anyone know of a utility that can display and change the values
eptember 15, 2010 3:42 PM
>>To: IBM-MAIN@bama.ua.edu
>>Subject: Re: Initiators
>>
>>On Wed, 15 Sep 2010 16:06:55 -0400, Thompson, Steve wrote:
>>
>>>Each initiator, drained or running, takes up room in the SQA for ASCBs
>>>and such.
>>
>>An ad
On Thu, 16 Sep 2010 08:09:28 -0500, Mark Zelden wrote:
>
> The ASCB (at least in z/OS 1.11) is 384
>bytes and is located below the 16M line. It would be a very bad thing
>if they were all allocated / reserved based on MAXUSER.
>
I meant to write... "would have been" in the context of MVS history
for them all at IPL
>time, then it doesn't matter whether some number of those ASCBs
>are allocated to drained initiators, does it?
>
May I assume this applies equally to address spaces created by BPXAS?
-- gil
--
F
On Wed, 15 Sep 2010 17:10:11 -0400, Thompson, Steve wrote:
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>Behalf Of Tom Marchant
>Sent: Wednesday, September 15, 2010 3:42 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: Initiators
u] On Behalf
Of Ted MacNEIL
Sent: Wednesday, September 15, 2010 Wednesday 4:01 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Initiators
>Why not just put them under WLM control, and then the system controls
how many you use (up to your set limits)? This is much easier than manually
stopping and
>Why not just put them under WLM control, and then the system controls
how many you use (up to your set limits)? This is much easier than manually
stopping and starting initiators, and it takes the control away
from operators who usually do not understand the impact starting too many
initiat
>Wouldn't you be better served by putting the initiators under WLM control?
>Then you would have as many initiators as you need without over committing CPU.
1: WLM managed inits are not a panacea.
2: Undisciplined operators can still wreak havoc.
-
I'm a SuperHero with nei
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Tom Marchant
Sent: Wednesday, September 15, 2010 3:42 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Initiators
On Wed, 15 Sep 2010 16:06:55 -0400, Thompson, Steve wrote:
>Each initiator, drai
Thanks everyone for your replies. We haven't started using WLM YET, but I'll
look into it.
Thanks again.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GE
rained initiator.
I agree with Dave O'Brien. WLM managed initiators are a good thing
as long as they work for you.
--
Tom Marchant
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.
Why not just put them under WLM control, and then the system controls
how many you use (up to your set limits)? This is much easier than
manually stopping and starting initiators, and it takes the control away
from operators who usually do not understand the impact starting too
many initiators
Wouldn't you be better served by putting the initiators under WLM control? Then
you would have as many initiators as you need without over committing CPU.
Thank You,
Dave O'Brien
NIH Contractor
From: McKown, John [john.mck...@healthmarkets
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of gsg
Sent: Wednesday, September 15, 2010 2:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Initiators
Is there any reason why you shouldn't have alot of initiators defined,
but have
alot of
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of gsg
> Sent: Wednesday, September 15, 2010 2:56 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Initiators
>
> Is there any reason why you shouldn't have alot
Is there any reason why you shouldn't have alot of initiators defined, but have
alot of them drained. Is there any performance considerations?
Thanks
--
For IBM-MAIN subscribe / signoff / archive access instructions,
Works just fine in a MONOPLEX. I am doing it now. Additional initiators
are started/stopped based on the mix of work currently in the system. If
you have some mix of JES and WLM managed inits, this can be used (as one
example) to limit test/dev work when production is heavy.
Pay close attention
Having WLM manage the initiators will prevent new jobs from entering the system
when the system is at 100%. This is good from a performance viewpoint. Users
tend not to understand that and want to know why their job isn't running. Also
if you are currently using Jes2 Priority, be prepare
I am reading about the WLM Managed Initiator possibility. As fas as I
understand, the option is designed to use it in a Sysplex environment with
mutiple systems. Are there any advantages and/or disadvantages when
activating it in a Monoplex environment (so only on a single system) or is it
of
On Mon, 2009-09-14 at 06:48 -0400, Gil Peleg wrote:
> We have some code in IEFACTRT that issues WTO messages with route code 11
Yes, we changed our ACTRT to issue messages with another route code so
to avoid those superfluous (IMO) IEF196I messages.
--
David Andrews
A. Duda and Sons, Inc.
david.
ssage is echoed
again with IEF196I message.
I know that is what IEF196I is for.
I see IWM034I stating that the WLM-managed initiator was started with
parameters SUB=MSTR.
But isn't that behavior of WLM-managed initiators inconsistent with the
behavior of JES-managed initiators?
Shouldn
ive.
I had great results with WLM initiators when I went to OS/390 2.4. I think
it might have helped that all of my batch goals were response time goals. I
made sure that none of my goals were too aggressive and for batch I used
fairly low percentiles on my response time goals. At the time of the
up
On Tue, 17 Feb 2009 16:19:29 -0600, Field, Alan C.
wrote:
>We are a JES2 shop, z/OS 1.8 going to 1.10.
>
>
>
>We have two production LPARS in a parallel sysplex.
>
>
>
>CLASS=A work can run on either lpar
>
>
>
>Because the job scheduling package runs on only one lpar is tends
>overload its
We are a JES2 shop, z/OS 1.8 going to 1.10.
We have two production LPARS in a parallel sysplex.
CLASS=A work can run on either lpar
Because the job scheduling package runs on only one lpar is tends
overload its lpar.
We've tried to manage the number of inits manually to balance t
Looks like one of those packages - commercial, or non-commercial are
looking better and better.
Stephen McColley
On Wed, 2008-08-13 at 10:27 -0700, Edward Jaffe wrote:
> Bob Rutledge wrote:
> >
> > Yep, and it almost works for the Gadi's requirement :(
> >
> > $TJOBCLASS(Q),XEQMEMBER(Z890)=(MAXIMU
Bob Rutledge wrote:
Yep, and it almost works for the Gadi's requirement :(
$TJOBCLASS(Q),XEQMEMBER(Z890)=(MAXIMUM=0)
$HASP003 RC=(08),T 344
$HASP003 RC=(08),T JOBCLASS(Q) XEQMEMBER(Z890) MAXIMUM - VALUE
$HASP003 IS OUTSIDE NUMERICAL RANGE, RANGE IS
$HASP003 (1-4294967295)
On Wed, 13 Aug 2008 12:14:12 -0400, Stephen McColley <[EMAIL PROTECTED]>
wrote:
>I suppose I should have been a bit more specific - during our
>maintenance window we typically want to stop all initiator classes
>except one which we use to run our maintenance job in. The $PXEQ will
>stop everythin
I suppose I should have been a bit more specific - during our
maintenance window we typically want to stop all initiator classes
except one which we use to run our maintenance job in. The $PXEQ will
stop everything on that one system, and we still want to do some work -
it's just very selective.
On Wed, 13 Aug 2008 08:50:09 -0500, Stephen G. McColley
<[EMAIL PROTECTED]> wrote:
> The problems can get more
>complex when you want to stop jobs on only one system for a maintenance
>window for example so this should not be unique to your shop...
>
That has never been a problem. $PXEQ is sing
Hi,
We implemented WLM managed inits in our shop back at 1.7, and ran into
some of the same issues with WLM mangaged init - YES - if you change the
class to wlm managed it takes effect for the entire mas, and at least prior
to 1.9 (I haven't checked 1.9 yet), you could set a class limit but that
Take care if you've assigned a resource group capping for these batch
because WLM doesn't take into account this type of delay (RGC-delay).
If your system is not saturated, WLM will continue to start new inits as more
jobs are submitted.
Regards
Edward Jaffe wrote:
Bob Rutledge wrote:
Edward Jaffe wrote:
This has always been a trivial setting for JES3 (EXCRESC for the job
class group) and the lack of this capability in JES2 was a glaring
omission. To compensate, the most recent JES2 releases implement a
maximum XEQCOUNT by member by
Bob Rutledge wrote:
Edward Jaffe wrote:
This has always been a trivial setting for JES3 (EXCRESC for the job
class group) and the lack of this capability in JES2 was a glaring
omission. To compensate, the most recent JES2 releases implement a
maximum XEQCOUNT by member by class.
XEQCOUNT has
Gadi, John,
>The WLM managed initiators are defined on a sysplex level. Once you tell
JES that a particular class is WLM managed, it will run jobs >on all (in
our case both) system in the sysplex.
WLM initiators are defined on a JESPLEX level, not a Sysplex Level. Of
course, if your Syspl
Edward Jaffe wrote:
bci ao `ai wrote:
Hi,
We would like to use WLM managed initiators for some of our classes.
The jobs running in these classes can only run on one of the systems
in our sysplex.
Is there a way to make sure that the jobs will run on oe system other
that using /*JOBPARM
Actually, IBM recommends using both types of initiators depending on the
type of work. Specifically, production batch under JES2 and the rest
under WLM.
Anyway, Scheduling Environments will segregate the work. Define an
unique SE for each LPAR or member of the MAS, e.g. LPAR1, LPAR2 ...
Define
I prefer using scheduling environments. In our environment, we set up
scheduling environments to handle most jobs by supplying it in several JES2
exits.
However, one issue scheduling environments does not address is JCL
conversion. Conversion could occur on any system in the MAS. Most jobs ha
bci ao `ai wrote:
Hi,
We would like to use WLM managed initiators for some of our classes.
The jobs running in these classes can only run on one of the systems in our sysplex.
Is there a way to make sure that the jobs will run on oe system other that using /*JOBPARM SYSAFF=?
This has
>>I wouldn't mix up WLM & JES management in the same MAS.
>Why?
I was responding to John's comment about mixed for the same jobclass, I meant
what John said about two types of management for the same jobclass -- which at
the time I responded, I had forgotten that a jobclass is sysplex wide.
>
On Sun, 10 Aug 2008 21:38:12 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote:
John wrote:
>>I'm not really very knowledgable about WLM initiators, but wouldn't it be
possible to only tell the JES2 on a particular system to service a specific
class? E.g. JES2 on SY1 has
initiators
___
Note: This e-mail is subject to the disclaimer contained at the bottom of this
message.
___
> -Original Mess
age-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of ??? ?? ???
> Sent: Sunday, August 10, 2008 3:16 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: WLM managed initiators
>
> Hi,
>
> We would like to use WLM managed initiators for some of our classes.
Hi John,
The WLM managed initiators are defined on a sysplex level. Once you tell JES
that a particular class is WLM managed, it will run jobs on all (in our case
both) system in the sysplex.
We found this out the hard way.
Gadi
-Original Message-
From: IBM Mainframe Discussion List
>I'm not really very knowledgable about WLM initiators, but wouldn't it be
>possible to only tell the JES2 on a particular system to service a specific
>class? E.g. JES2 on SY1 has a JOBCLASS(C) MODE=WLM defination in it. JES2 on
>SY2 has JOBCLASS(C) MODE=JES and doe
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of ??? ?? ???
> Sent: Sunday, August 10, 2008 3:16 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: WLM managed initiators
>
> Hi,
>
> We would like to use WLM mana
Hi,
We would like to use WLM managed initiators for some of our classes.
The jobs running in these classes can only run on one of the systems in our
sysplex.
Is there a way to make sure that the jobs will run on oe system other that
using /*JOBPARM SYSAFF=?
TIA
Gadi
ssion List
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
JES2 $TI or $SI command on initiators over initiator 99 return invalid
I need to pull out my WLM Managed Initiators to prepare for the
outsourcer. In preparation, in testing, when we issue a $TI or $SI for
initiators after initiator 99 I get &quo
I need to pull out my WLM Managed Initiators to prepare for the
outsourcer. In preparation, in testing, when we issue a $TI or $SI for
initiators after initiator 99 I get "$HASP650 IA0 INVALID OPERAND OR
MISPLACED OPERAND". Anyone hit a similar problem or have a solution, we
a
NOTICE:
All information in and attached to the e-mail(s) below may be proprietary,
confidential, privileged and otherwise protected from improper or erroneous
disclosure. If you are not the sender's intended recipient, you are not
authorized to intercept, read, print, retain, copy, forward, or
opies of this message
(electronic, paper, or otherwise). Thank you.
>
> Is there any way using SMF data that I can see what initiator a job
was
> running in? I am trying to develop a map of what was running on a
> system at a particular time (jobs only) and it occurred to me that if
I
>
what initiator a job was
running in? I am trying to develop a map of what was running on a
system at a particular time (jobs only) and it occurred to me that if I
can somehow see what was in the initiators when, I've got what I need.
Thanks in advance,
Jim Horne
Lowe's Companies
System
<[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> Hi, all
>
> We just began to use WLM initiator in our test system. It is a 6 LPARs
> SYSPLEX, the CPU is not so busy, about 60% or less at batch time. When we >
> check SMF30SQT for our batch jobs, we find that for JES2 initiator
Hi, all
We just began to use WLM initiator in our test system. It is a 6 LPARs
SYSPLEX, the CPU is not so busy, about 60% or less at batch time. When we
check SMF30SQT for our batch jobs, we find that for JES2 initiator, the
average is 3887, and the maximum is 12616, remember the unit is 1024
68 matches
Mail list logo
