I have been meaning to post IBM's explanation of this problem. I hope I explain this correctly. I will paraphrase.
From a conference call about 2 weeks ago: IBM fixed a bug in 'base code' at 1.13. The bug was that whenever a batch job performed vsam i/o, it was switched to the highest priority (this is normal), but then, when control was given back to the application task after the i/o, it continued to run at the highest priority INSTEAD OF the assigned WLM service class, which in our case was called BATPRDMED. Our temporary workaround, in order to get the service we were used to on v1.11, has been to set these jobs to a 'hotter' service class, BATHOT. IBM told us there was no tech doc or apar to document this change. What we observed (and possibly you?) when we brought up v1.13 was their 'fix' to this problem. The batch jobs were now running in the correct service class (WAD). They did not tell us exactly when the problem was introduced. A few days after this explanation 'soaked in', I suddenly remembered several instances, when we were on zOS v1.11, where batch jobs had preempted our online regions, which are supposed to ALWAYS run with higher priority than batch. I remember thinking that we had a problem at that time, though we never pursued it with IBM. I have now convinced myself that this was the manifestation of the bug they fixed at 1.13. While the lack of doc and background info was upsetting, I think IBM made an honorable attempt to 'make up for it' by providing some very helpful vsam tuning advice. I have to say their advice has improved our batch performance significantly. Their advice was to implement SMB in our long-running batch vsam jobs. We are a VSAM-centric shop with only a tiny bit of DB2, so we were probably impacted more than the typical shop. HTH, -Jim ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
