Since this makes most uses of a GDG single threaded, would it make sense to force large GDG files to VTAPE from disk? I assume this would be implemented with statements in the ACS routine? Anyone have a sample?
On Fri, Aug 5, 2011 at 10:03 AM, Joel C. Ewing <jcew...@acm.org> wrote: > 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 > -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- 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
