On 08/05/2011 06:49 AM, Lizette Koehler wrote:
Questions :
During a GDG recall, the HSM keep in exclusive mode all versions of the
dataset and
cannot create new versions till tne recall ends?
Is it normal behaviour of the HSM or is there some "parameter" to avoid
this?
Best regards and happy weekend.
Enrique Montero
It is normal behavior for a GDG in general.
The enq is placed on the GDG base not the individual GDG entry. So if any
long running job is creating a GDG +1, it will be the base name that is
enqueued.
I do not know if IBM was ever asked to address this concern.
Lizette
IBM would have to be very careful how they touched this code, as there
are risks a change might cause more problems than it solved. I believe
both GDG base and GDS enqueues are involved in a relative GDG reference,
but there are specific conventions about order and type of enqueue.
The GDG base enqueue is what protects against two concurrent new GDS
creations by two unrelated programs in order to guarantee consistent
assignment of G0000V00 ordinals and consistent cataloging of new
generations, including the case where a step ABEND results in subsequent
deletion of the GDS. It also protects against resolving a GDG relative
generation reference at times when the generations are in transition.
Having two tasks with conflicting GDS creations running at the same time
is potentially a scheduling/application-design error as there is no
guarantee which process gets the GDG enqueue first, so from the end
user's viewpoint the process may appear non-deterministic, even though
it is deterministic and consistent from the view of MVS.
A DFHSM recall of a GDS is physically updating the GDS by moving it,
even though the job step intent may be to read, so this muddles the
waters as to what kind of enqueues may be required and appropriate. As
long as the GDS can't be deleted by the step doing the recall, there
shouldn't be any need to modify the GDG base itself so a GDG base
enqueue might seem unneeded; but what might happen if some other process
attempted to delete the GDS by relative generation number while the
recall was in progress?
It used to be there were some methods of getting access to a GDS, like
ISPF browse or JCL reference by specific G0000V00 number, that bypassed
any enqueue on the GDG base and only enqueued the GDS; and that in some
cases this could blow away (ABEND) a batch job step trying to access the
same GDG family by relative generation: the relative GDG JCL/batch
allocation logic assumed/required that the proper GDG base enqueue
preceded the GDS enqueue and it couldn't tolerate an enqueue failure on
the GDS that it "knew" should have worked after enqueueing the base.
So, failure to enqueue the GDG base at all or using enqueues that are
inconsistent with existing GDG enqueue conventions has introduced
problems in the past. This is not to say change is impossible or
undesirable, only that finding and fixing unintended side effects may
not be trivial. This is in an area where omitted GDG base enqueues in
the past have produced production batch ABENDs.
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
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
