Re: IDMS batch jobs getting increased dispatching priority
On Thu, 10 Apr 2008 15:18:49 -0400, Jack Kelly <[EMAIL PROTECTED]> wrote: >Up front, I have to say that I know less than zero about IDMS and I was >hoping to keep it that way. >We have a rash of batch jobs extracting data from IDMS regions. God only >knows what they're doing but these jobs seem to have their dispatching >priority increased to FC range where their srvclass should have them in >the high C0 to low E0 range. The only enque that appears is 'IDMSCV BATxx' >(where xx is some hex characters). I was thinking that it could be ERV >trying to elimate enque contention but that doesn't seem to be the case. >This enque seems to be an IDMS mechanism to serialize batch usage. >Any thoughts? > Check into APAR OA22795. We were burned by this when we upgraded from MIM 11.5 to MIM 11.6. See the archives for details on that. APAR Identifier .. OA22795 Last Changed 08/01/02 DISPATCHING PRIORITY OF BATCH REMAINS HIGH AFTER ENCLAVE LEAVE It affects z/OS 1.6 through z/OS 1.9. Also see OA18823 which I did have on at the time. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: IDMS batch jobs getting increased dispatching priority
When a batch job uses services of an IDMS Central Version, it works like
this:
The batch job makes a request of the IDMS central version (used to be via
an SVC), then waits.
The IDMS central version processes the request - at the IDMS CV's
dispatching priority. When the request finishes, CV posts the batch job.
The ENQ is how the IDMS Central Version recognizes when a batch run unit
"goes away" without committing. The batch job latches onto an ENQ before
it issues an IDMS "BIND" call. As part of its BIND processing, the
Central Version attempts to ENQ on the same resource name. If CV (the
central version) actually gets control of the ENQ, it knows that the batch
run unit went away without saying goodbye ("COMMIT"), so it initiates a
rollback.
Makes life interesting.
Ancient Chinese curse: "may you live in interesting times".
Tom Puddicombe
Mainframe Performance & Capacity Planning
CSC North American Public Sector - Civil Group
Computer Sciences Corporation
Registered Office: 3170 Fairview Park Drive, Falls Church, Virginia 22042,
USA
Registered in Nevada, USA No: C-489-59
-
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.
-
Jack Kelly <[EMAIL PROTECTED]>
Sent by: IBM Mainframe Discussion List
04/10/2008 03:18 PM
Please respond to
IBM Mainframe Discussion List
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
IDMS batch jobs getting increased dispatching priority
Up front, I have to say that I know less than zero about IDMS and I was
hoping to keep it that way.
We have a rash of batch jobs extracting data from IDMS regions. God only
knows what they're doing but these jobs seem to have their dispatching
priority increased to FC range where their srvclass should have them in
the high C0 to low E0 range. The only enque that appears is 'IDMSCV BATxx'
(where xx is some hex characters). I was thinking that it could be ERV
trying to elimate enque contention but that doesn't seem to be the case.
This enque seems to be an IDMS mechanism to serialize batch usage.
Any thoughts?
Jack Kelly
202-502-2390 (Office)
--
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
--
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
Re: IDMS batch jobs getting increased dispatching priority
>dispatching priority increased to FC range where their srvclass should have >them in the high C0 to low E0 range. Do NOT worry about dispatching priority in Goal Mode. The WLM/SRM tandem manipulates them, as needed, to meet goals. They are irrelevent, as long as goals are met. Cheryl Watson (and others) have been preaching that for years, and nobody seems to listen. - Too busy driving to stop for gas! -- 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
Re: IDMS batch jobs getting increased dispatching priority
On Thu, 10 Apr 2008 22:16:01 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >>dispatching priority increased to FC range where their srvclass should have them in the high C0 to low E0 range. > >Do NOT worry about dispatching priority in Goal Mode. >The WLM/SRM tandem manipulates them, as needed, to meet goals. >They are irrelevent, as long as goals are met. >Cheryl Watson (and others) have been preaching that for years, and nobody seems to listen. > In general, you are correct. But in this case it could have (or could be) relevant. FC is not in the range of WLM controlled DPs for z/OS 1.8 and above. Also see the APAR I quoted in an earlier reply. What I didn't get from the first post was if this just started happening or not. Here is a table of DPs from the System Programmer's Guide to: Workload Manager Redbook - SG24-6472-03: Table 2-1 Dispatching priorities prior to z/OS 1.8 255 FF SYSTEM 254 FE SYSSTC 253 FD Small consumer 252-208 FC-D0 Dynamically-managed DPs 207-202 CF-CA Not used 201-192 C9-C0 Discretionary 191 BF Quiesce Table 2-2 Dispatching priorities as of z/OS 1.8 255 FF SYSTEM 254 FE SYSSTC, SYSSTC1-5 253-249 FD-F9 Reserved 248 F8 Small consumer 247-203 F7-CB Dynamically-managed DPs 202 CA Not used 201-192 C9-C0 Discretionary 191 BF Quiesce Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: IDMS batch jobs getting increased dispatching priority
What I didn't get from the first post was if this just started happening or not. This appears to have happened periodically. The remedy has been to start changing srvclass and that made everyone happy-nothing changed but they felt like they were doing something. I got involved yesterday and Mark's suggested APARs was good but we don't use wlm inits and we're at MIM11.5. Received and applied them to our sandbox though. Really looks like the problem is IEAOPTxx ERV default and IDMS enque 'conflict'. On a small box that is a large portion. Reduced it to a reasonable number, at least in my world, and it's mitigated the problem. Now going to check with IBM and CA to see if there's a way to exempt some qnames from ERV consideration- yeah right! Jack Kelly 202-502-2390 (Office) -- 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
Re: IDMS batch jobs getting increased dispatching priority
IDMS mechanism to serialize batch usage Just thought that I'd give a final update to this issue in case it's of any interest to other parties. IDMS batch indeed serializes on a planned ENQ conflict. 'Enqueue Promotion' notifies SRM and SRM boost the service of the holder (in this case the IDMS batch job) for ERV (default: 500 CPU SU's). In our scenario, the batch IDMS jobs were executing at a higher dispatching priority than the rest of batch, even as high as the IDMS', even though these batch jobs were in a discretionary Service Class. Since I had the default ERV, i.e. no IEAOPTxx member, and we have a small processor, these batch job ate the box. I did turn off ERV and the processing smoothed out, changing it to a much smaller number made things less worse but not better. Of course CA thinks that this is an IBM problem, IBM rightly (I think) disagrees, and CA can not (or won't) change the way IDMS serializes batch work (it's worked for years, so why change!). Jack Kelly 202-502-2390 (Office) -- 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
Re: IDMS batch jobs getting increased dispatching priority
On Tue, 15 Apr 2008 12:03:58 -0400, Jack Kelly <[EMAIL PROTECTED]> wrote: > >IDMS mechanism to serialize batch usage > > >Just thought that I'd give a final update to this issue in case it's of >any interest to other parties. >IDMS batch indeed serializes on a planned ENQ conflict. 'Enqueue >Promotion' notifies SRM and SRM boost the service of the holder (in this >case the IDMS batch job) for ERV (default: 500 CPU SU's). In our scenario, >the batch IDMS jobs were executing at a higher dispatching priority than >the rest of batch, even as high as the IDMS', even though these batch jobs >were in a discretionary Service Class. Since I had the default ERV, i.e. >no IEAOPTxx member, and we have a small processor, these batch job ate the >box. I did turn off ERV and the processing smoothed out, changing it to a >much smaller number made things less worse but not better. >Of course CA thinks that this is an IBM problem, IBM rightly (I think) >disagrees, and CA can not (or won't) change the way IDMS serializes batch >work (it's worked for years, so why change!). > We run CA-Dispatch which utilizes IDMS as its online TP. We also run the archive and extract tasks externally to the Dispatch region and after you last post I looked at the behavior you described. I didn't see it. The extract and archive tasks run at the DP I expect them to in regards to the service class I have those STCs defined in. Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
