On 8/30/2013 11:55 AM, Joel C. Ewing wrote:
A highly counter-intuitive case for many new users used to be the case of a DDNAME with concatenated tape data sets, where the data sets are obviously constrained to access in sequential fashion; but the MVS default (without UNIT=AFF) was to allocate separate tape drives concurrently for each of the concatenated tape data sets, and then proceed to use them one at a time -- a highly antisocial act in environments with limited drives.
This appears to be a no-win situation for IBM. Our systems used AVR, and had enough drives, so that for us it was more important to reduce tape mount delays (while the job sat occupying limited storage). A full tape can take up to 4 minutes to rewind, in which time we could run four dozen non-setup jobs in that region. (Although later on, we used a memory-fencing mod from Share to reduce memory related delays)
Furthermore, it is logically impossible for the scheduler to determine which DDs could be assigned to the same drive. Assume my job to have three DDs, A, B, C; which two (or three) can safely share a drive? Without an explicit JCL assignment, you'd wind up with a lot of weird problems. If, alternatively, the drives are assigned dynamically at Open time, you can run into deadlocks with other running jobs.
About the worst case I have ever heard about came second-hand from a friend. He reported that a "CoBOL" programmer submitted a sort job with all sort work files on the same 2321 data cell drive!
Gerhard Postpischil Bradford, Vermont ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
