"Raupach, Robert E , ISD, IT" <[email protected]> wrote in message news:<listserv%[email protected]>... > Question about enqueues and reserves. We recently encountered the > following situation. > > A batch job held a shared enqueue to a user catalog. Waiting behind this job > was an exclusive CATALOG enqueue request. In addition, there were a > number of batch jobs and started tasks, including the JES3 Converter > Interpreter and DSFHSM also waiting for the user catalog. > > Batch and TSO access was hindered because the converter interpreter was > waiting for access to user catalog. > > Eventually, the problem "cleared itself" and processing continued. Since we > have a tight batch window, I need to investigate further. We were told that > 15 minutes before the initial job hung, system backups on HSM pool packs had > completed and that any reserve on the pack containign the user catalog
> would have been released. > > The system programming team thought the problem was with the batch job > that actually hung waiting for the user catalog. There's nothing unusual with > the batch job. It's been running for years without incident. The problem has > recurred with a different batch job, different user catalog on a different pack. > > We're running z/OS 1.8 with JES3. > > So, my questions are - could something (storage backups) have not cleared > the reserve that it put on the pack after the backups ended? Something > else? How could I investigate this further? > > Feel free to email off list. > thanks, > Bob R > Bob, First, you don't mention you received IOS071I Start Pending messages, so I think you don't need to worry about Reserves, but focus on the chain of Enqueues, that slowed down your system. Second, how busy was you CPU at that moment and what Service Class is the job running in? We had a more or less similar situation a few years ago, where a job had an enqueue outstanding on a usercatalog, but did not receive any CPU to complete its processing and release the enqueue in reasonable time. By the way, I consider this a bug in Catalog processing, that CAS allows itsself to be cornered this way by a simple low priority batch job. Kees. ********************************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ********************************************************************** ---------------------------------------------------------------------- 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
