[bit.listserv.ibm-main] Device Allocation

SYSKEC@GSUVM1.BITNET (02/08/90)

Here is the situation:

     MVS/XA 2.2.0 & JES 2.1.5

     1 3420 online
     7 offline
     The online 3420 is allocated to Job A
     Job B starts and needs 1 3420
     IEF238D ... REPLY DEVICE NAME,'WAIT', OR 'CANCEL
     Reply WAIT
     IEF433d ... REPLY 'HOLD' or 'NOHOLD'
     Reply HOLD
     Vary another 3420 online
     Job C starts - A 1 step job that writes to a 3420
     The mount message never comes up
     RMFWDM shows that JOB C is waiting exclusively for resource
     SYSIEFSD.Q4 and that Job B owns it shared

     When Job A completes Job B and Job C mount messages appear

     I understand Job B is waiting on Job A's 3420, but I don't understand/like
     Job C waiting.  This is repeatable and does not happen if the replyto
     IEF433D is NOHOLD.  I do have a sneaking suspicion that the answer to
     all this is 'works as designed', but I have'nt found any documentation
     admitting it.

                                              Keith Campbell
                                              SYSKEC@GSUVM1.BITNET
                                              Ga. State University
                                              Systems Programming

LDW@USCMVSA.BITNET (Leonard D Woren) (02/08/90)

It's probably "working as designed."  Replying 'HOLD' to that message
is so bad that I use TSSO (an automated console operations tool) to
always reply NOHOLD.  Doing so causes the WTOR for "reply ... WAIT or
CANCEL" to be reissued more often, but it's better than tying up
everything waiting for a drive to be freed up.

Leonard D. Woren
Senior MVS Systems Programmer
<LDW@USCMVSA.BITNET>  <LDW@MVSA.USC.EDU>
University of Southern California

SYSBILL@UKCC.BITNET (Bill Sallee) (02/08/90)

For the last few days I've been getting two copies of everything on this
list--one from AKRONVM and another resent from TREARN.

Bill Sallee University of Kentucky

PAPP@BCVMCMS.BITNET (John F. Papp) (02/08/90)

You're right.  It is working as designed.  The answer is in what you've
told the system to do.  When you reply "HOLD", you are saying you want
the job to hold on to all current allocations and wait until this
particular allocation can be resolved via the available devices at the
time.  It doesn't change when you bring on a new device and locks up
allocation for that class device until one is freed.

Generally, you want "NOHOLD" as a default.  This will release all
currently allocated resources and allow you to bring online similarly
classed devices.  Also, I would normally bring the device online via the
request not a vary command.

-John-

SYSKEC@GSUVM1.BITNET (02/09/90)

Yep, Its official according Level 2 and every reply I received it works as
designed.  The messages manual's entry for 'IEF433D .. REPLY 'HOLD' OR 'NOHOLD'
could be a lot more informative!

A job waiting on a unit to come available is actually waiting for an eligible
unit to go through unallocation.  The only place the waiting job is posted is
unallocation.  Level 2 said they had closed an APAR and accepted a suggestion
to have a vary online of an eligible unit to post the waiting task.


                                         Thanks for all the help
                                         (and I promise to never
                                          never answer HOLD)

                                          Keith Campbell
                                          SYSKEC.GSUVM|.BITNET
                                          Ga. State University
                                          Systems Support