Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
Hi,
QW on UNIT gives the definiton of DEFER as:
DEFER asks the system to assign device(s) to the data set but not to mount the volume(s) until the data set is opened - if the data set is not opened, no mount occurs - do not code DEFER on a SYSCKEOV DD statement.
In above, what's the meaning of the line
Quote:
not to mount the volume(s) until the data set is opened
1. I would like to know, what physically happens to DASDs when DEFER is coded as an argument in UNIT parameter?
2. I used to think mount is meant for TAPE devices only, what's the meaning of mount from DASD point of view?
3. If the DASD is mounted for a particular JOB, I think it cann't be used by any other JOB, if yes, then what's the meaning of above quoted line? Because I'm, as an end user, already charged for the DASD usage. What difference(both, execution of JCL & charges applied for DASD usage ) will it make if I code UNIT=SYSDA & UNIT=(SYSDA,,DEFER)
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
DEFER is ignored for DASD devices. If you think about it, how can you defert the mount of something already mounted ?
MOUNT attributes for DASD is historical, except for non SMS volumes which in 99.99% of cases are system volumes. So there again nothing to think about.
DEFER for tape - The tape mount request to the operating system will not be issued until the executing program issues an OPEN for that DD name. So if your program has no data to write, then a tape volume will not be mounted.
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
Thanks Expat.
Got my queris cleared. Actually, below statement made me thought about DEFER for DASDs.
Quote:
UNIT=(3400-6,,DEFER)
I'm an application programmer, so didn't have enough experience with mounting/de-mounting terminologies. What I can think of is that, 3400-6 is a type of tape drives like 3420 Tape Drives, which in turn are Reel Type tape dreives, right? I'd taken the above example as if it's for DASDs so the original post comes.
One more query to ask, about
Quote:
The tape mount request to the operating system will not be issued until the executing program issues an OPEN for that DD name.
For tape drives, firstly operating-system issues an OPEN, only after that tape can be mounted, right? If so, does that mean if the tape is not OPEN/mounted for my job, me, as an end user, will not be charged for that tape?
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello Anuj,
The DEFER was to help the computer operators "in the old days". Today most tapes are mounted by robots. Previously every tape was retrieved from the library and placed on a tape drive manually.
Using DEFER saved unneeded physical tape mounts and saved much confusion in the data center. If a tape might or might not be created, the operators were not always sure whether to label and keep the tape (yup, tapes had external labels that described the data on the tape - today, only the volser is usually visable externally) or return it to the "scratch pool". Similar advantage with the optional input tape. If a process uses a particular input tape every run except for the first of the month (when a new file was started) the optional input would be DEFER mounted.
With the mount deferred, the drive is still allocated, just the mount is not issued until the process actually opens the file. If you look at the JES joblog for a job that uses tape, you will see something like:
Code:
*IEF233A M 0636,0965MS,,MSRDSEDF,STEP1
IEC502E K 0636,0965MS,SL,MSRDSEDF,STEP1
which tell the operator to Mount the tape and later Keep the tape. With DEFER, these messages will not be issued unless the file is OPENed.
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
Thanks Dick.
I am again hungry to know some more
dick scherrer wrote:
Previously every tape was retrieved from the library and placed on a tape drive manually.
Does that mean in those days, if some user submits a JCL with 10 tape-files, then ten operatos or one operator ten-times will go to library & mount all the tape files (if JCL needs all the tape files). If this, what about the CPU time for that JOB?
Quote:
Using DEFER saved unneeded physical tape mounts and saved much confusion in the data center. If a tape might or might not be created, the operators were not always sure whether to label and keep the tape (yup, tapes had external labels that described the data on the tape - today, only the volser is usually visable externally) or return it to the "scratch pool".
This sounds something intelligent. Here one thing to ask, when you say,
Quote:
return it to the "scratch pool".
It means that tape file is not mounted yet so back to the library aka "scratch pool"?
Quote:
Similar advantage with the optional input tape.
What's the meaning of optional input tape?
Quote:
With the mount deferred, the drive is still allocated, just the mount is not issued until the process actually opens the file.
So as an end user, am I charged for this not-mounted tape?
Quote:
If you look at the JES joblog for a job that uses tape, you will see something like:
Code:
*IEF233A M 0636,0965MS,,MSRDSEDF,STEP1
IEC502E K 0636,0965MS,SL,MSRDSEDF,STEP1
which tell the operator to Mount the tape and later Keep the tape. With DEFER, these messages will not be issued unless the file is OPENed.
Does this mean, in old days, operators used to see the JES joblog of every JOB which make use of tape files,if yes, how they used to manage this type of labour work?
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
You're welcome
Quote:
Does that mean in those days, if some user submits a JCL with 10 tape-files, then ten operatos or one operator ten-times will go to library & mount all the tape files (if JCL needs all the tape files). If this, what about the CPU time for that JOB?
In those days "users" typically did not submit their own jobs. Many data centers had a scheduling&control section and if a user wanted an on-request job or some other non-regularly scheduled activity to happen, they communicated with the control/scheduling people to get things going. Once the job(s) made it to that day's schedule, someone (thruput operator or tape librarian) "staged" the jobs by pulling the needed tape(s) or anything else that was needed to run the job (like printing checks which were printed on line printers, not laser printers). When the job ran, the computer operators only needed to pick up the tape(s) and place them on a drive. While waiting on a tape mount there is no cpu time used. Waiting on tape mounts does tie up tape drives and initiators/partitions which hurts overall throughput.
Quote:
Quote:
return it to the "scratch pool".
It means that tape file is not mounted yet so back to the library aka "scratch pool"?
Usually a large portion of the scratch pool was near the tape drives - to reduce the time needed to get and mount the scratch tape. If a tape was never mounted as output, just sat on the rack and no action was needed.
Quote:
What's the meaning of optional input tape?
Some jobs had an input file that was only used on certain runs - not every run. If defer mount was specified, the operator did not have to handle that tape for that run. The tape drive is still allocated, but there is no operator intervention needed.
Quote:
So as an end user, am I charged for this not-mounted tape
Probably not as there is no chargable activity.
Quote:
Does this mean, in old days, operators used to see the JES joblog of every JOB which make use of tape files,if yes, how they used to manage this type of labour work?
In those "old days" the console log was the "bible". Keep in mind, there were no glass-terminal consoles - the console printed every line on a printer that was physically part of the concole (very much like a "real" typewriter except that the paper was continuous feed rather than sheets). If there was a problem or some confusion, people had to page back thru the console log and determine what had happened.
Typically each mainframe had a "console operator" whenever the system was running (which was close to 24/7).
Joined: 28 Nov 2006 Posts: 305 Location: Deerfield IL
Long ago removable disk packs were mounted in disk drives. They needed to be mounted to be used so defer and retain were important for disks also.
In our shop tapes and carts from outside and tapes and carts intended to be sent outside the shop are not put in the siloes. So some poor human tape operator still has to find and mount these tapes and carts. To these operators it is very important that you use defer and retain properly.
In our shop we are charged for each actual mount. If 10 steps in one job allocate the same tape and neither defer nor retain is used, we will be charged for 10 mounts. If defer and retain are used we may be charged for zero or one mounts depending on if the datasets are opened.
If that human operator has to mount the same tape 10 times (possibly on 10 different tape drives) for the same job he will probably be upset with you. Even if this is being done by the tape silo it may take your job longer to run when the tapes are dismounted and mounted.
.jpg)
