<snip>
Can you elaborate on this? We are running IDMS DB and DC and aren't
seeing this issue. What resource are you enqueuing on?
<unsnip>
here's the update that I got from CA. Since we're a uniprocessor, my
solution was to
set ERV=0 which was the least worse solution.
Background from issue #17033487-01
In terms of the enqueuing of batch jobs in general, our process is:
1. When a CV batch job begins, it ENQUEUES SHARED on a MAJOR name of
IDMSCV
and a MINOR name of BATCxxxx, where xxxx is a binary time stamp.
2. When CV gets control, RHDCCKUR attempts an ENQUEUE EXCLUSIVE on the
same
MAJOR and MINOR names, but since the batch job still control of the
enqueue
names, it goes to sleep.
3. When the cv batch job terminates, RHDCCKUR will wake up and the CV
will
do the necessary cleanup for the batch job.
This poses a problem for IBM's WLM, ERV function. The 'sleep'
scenario
described above is making WLM 'misbehave'. WLM / ERV wants to increase
the priority of a task that holds an enque that someone else wants.
That's ERV's function. This was put in place to reduce enque lockouts,
ie low priority task has enque that a higher priority task need.
Even though IDMS isn't waiting on the enque, WLM 'sees' the conflict and
keeps trying to give the holder more cycles. Since the holder is batch,
the
user basically has a batch job sucking up all the resources and IDMS keeps
passing it data. This causes all CV activity to grind to a halt. When
the
batch job is a long-running one, it creates unacceptable delays for the
online system which is now running at a lower priority than the batch job.
WLM ERV is adjusting the zos dispatching priority of the jobs. This
gets boosted up into the F1, F2 range (higher than the IDMS CV's) for the
batch jobs; the client turns off ERV and the batch jobs stay where they
belong, ie high C0, low D0 range. This method of managing ENQ resources
was changed in z/OS 1.3. In this processing, ERV is overriding the
Service
Class management of batch jobs that we suggest in technote QI02781.
IBM has stated that their ERV funcionality is working as intended.
It
does not include a method for ignoring some jobs that hold an ENQUEUE, or
for
selectively implementing the feature. The client requests that we change
our
processing to use a RET=TEST on the enque instead of an EXCL request, or
that
we use POST to communicate serialization, so that this problem can be
avoided.
Level2 has said that the reason we do the ENQ is to allow the CV to
be
notified if the Batch job goes away for some reason. Without the ENQ the
batch job would remain active within the CV. This would result in
resources
being held indefintely (Storage, DBKEY locks, RCEs, RLEs, DPEs, etc.). We
We need the Batch job to hold the ENQ so when the CV CKUR task attempts to
get the ENQ it waits. If the batch job goes away, the CKUR acquires the
ENQ
and notifies the CV that things may need to be cleaned up.
Client feels that the current methodology is one way to do it BUT it
has
adverse affects on performance and should be changed. IBM has said ERV is
working as designed, so the CA IDMS approach has forced them to disable
an important vehicle to minimize contention. CV could issue EXCL enq and
if
it fails, then a batch job is executing. ---------------------------
Error
---------------------------
The operation completed successfully.
Jack Kelly
202-502-2390 (Office)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
