Re: DFHSM Recalls and Tape
Hi, because FBID order takes precedence over priority. Hence, if a user issues 1000 NOWAIT type recalls and there is a single WAIT type recall at the end of the same tape, then the Wait-type is going to be delayed until all of the NOWAIT type recalls are processed. The introduction of the serpentine read/write technology for tapes removed the advantage of processing in FBID order for random recalls. In fact, in can make performance worse because two close FBIDs are not necessarily physically close on a tape written 'serpentinely'. Performance Tests have shown that with random recalls, processing in FBID order does not necessarily drive better performance. Hence, it is generally better to process in priority order (Wait / Nowait) than FBID. The exception is when you know that you will have Many recalls from the same tape. In that case, processing in FBID can provide a significant performance improvement. We added this support for a particular customer had a Use Case where they would recall every data set off of a tape, for which processing in FBID order provided Significant Value. That said, this is a 'recommendation'. Since each environment is unique, it would be worthwhile to experiment with the setting in your environment. Glenn Wilcock DFSMShsm Architect -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
At last a definitive answer! Glenn, why would SETSYS TAPEDSORDER(RECALL(FBID)) be temporary? From your description I can't see any reason NOT to make it the operating norm. Thank You, Dave O'Brien NIH Contractor From: Glenn Wilcock [wilc...@us.ibm.com] Sent: Friday, October 12, 2012 11:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM Recalls and Tape In both a CRQ and nonCRQ environment, HSM will process all of the queued requests from a mounted tape. But, there are some important differences. In a nonCRQ environment, each HSM host has it's own queue. So, each host will only process the queued requests on it's own queue. This requires each host to mount/unmount the same tape. Also, the recall queue has to be sequentially scanned to find the next recall on the same tape. This may require alot of processing for large queues. In a CRQ environment, there is a shared queue, so the first host that mounts the tape will process ALL recalls in the HSMplex that require that tape. (Truly a single tape mount). Also, within the CRQ, a unique prioritized LIST is maintained for the recalls queued for each tape, so the next recall can be found with a single Request to the Queue, as opposed to having to scan the queue sequentially. When queuing thousands of recalls which will come from the same tapes, I recommend temporarily using SETSYS TAPEDSORDER(RECALL(FBID)). This will recall the data sets on the same tape in FBID order, which will give better performance since you will be driving many recalls from the same tape. For random recall activity, I would recommend RECALL(PRIORITY), which will process WAIT requests before NOWAIT type requests. Glenn Wilcock DFSMShsm Architect -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
Agreed. The HSM default is to hold a tape for 5 seconds to wait for another recall from the same tape to be queued. Either the next recall from the same tape is coming in after 5 seconds, or it is arriving on another LPAR (in a nonCRQ environment). Glenn Wilcock DFSMShsm Architect -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
In both a CRQ and nonCRQ environment, HSM will process all of the queued requests from a mounted tape. But, there are some important differences. In a nonCRQ environment, each HSM host has it's own queue. So, each host will only process the queued requests on it's own queue. This requires each host to mount/unmount the same tape. Also, the recall queue has to be sequentially scanned to find the next recall on the same tape. This may require alot of processing for large queues. In a CRQ environment, there is a shared queue, so the first host that mounts the tape will process ALL recalls in the HSMplex that require that tape. (Truly a single tape mount). Also, within the CRQ, a unique prioritized LIST is maintained for the recalls queued for each tape, so the next recall can be found with a single Request to the Queue, as opposed to having to scan the queue sequentially. When queuing thousands of recalls which will come from the same tapes, I recommend temporarily using SETSYS TAPEDSORDER(RECALL(FBID)). This will recall the data sets on the same tape in FBID order, which will give better performance since you will be driving many recalls from the same tape. For random recall activity, I would recommend RECALL(PRIORITY), which will process WAIT requests before NOWAIT type requests. Glenn Wilcock DFSMShsm Architect -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
Yes it can. And really should be the way to set up recalls because during maintenance, your primary LPAR doing the recalls may need to down and if you don't have a back up for this function then all your recalls will sit in the queue. Regards, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert A. Rosenberg Sent: Thursday, October 11, 2012 8:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM Recalls and Tape At 11:55 + on 10/11/2012, Hervey Martinez wrote about Re: DFHSM Recalls and Tape: >If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead" >and recall all files that are on the same tape. Also, with CRQ, you can >limit which LPARS will perform recalls and limit them in that manner >and all recalls will be routed to that LPAR. >Otherwise, the recalls happen one at a time in a FIFO manner. > >Regards, > >Hervey Thank You. Looks like CRQ is the right way to go since it insures that once a tape has been mounted, it will be used to restore all the files on that tape before moving on to another tape. I can see that this has a downside since a high priority recall can be postponed since it is coming from a different tape (a situation that might not occur with a FIFO if there was the ability to insert the request at the top of the queue). You note that CRQ can restrict which LPAR does the recall. Can it be set to allow more than one LPAR to run the recalls (each with its only tape volume to process). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
At 11:55 + on 10/11/2012, Hervey Martinez wrote about Re: DFHSM Recalls and Tape: If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead" and recall all files that are on the same tape. Also, with CRQ, you can limit which LPARS will perform recalls and limit them in that manner and all recalls will be routed to that LPAR. Otherwise, the recalls happen one at a time in a FIFO manner. Regards, Hervey Thank You. Looks like CRQ is the right way to go since it insures that once a tape has been mounted, it will be used to restore all the files on that tape before moving on to another tape. I can see that this has a downside since a high priority recall can be postponed since it is coming from a different tape (a situation that might not occur with a FIFO if there was the ability to insert the request at the top of the queue). You note that CRQ can restrict which LPAR does the recall. Can it be set to allow more than one LPAR to run the recalls (each with its only tape volume to process). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
At 10:10 -0400 on 10/11/2012, O'Brien, David W. (NIH/CIT) [C] wrote about Re: DFHSM Recalls and Tape: Elardus, I think you missed the distinction between submitting recalls and a process causing recalls. At this shop it was not unusual for a user to submit an Iefbr14 job to delete datasets thereby causing the recall of any dataset that had been migrated. Since the recall is serial, it would result in one tape mount per recall. Dave O'Brien Use of a DEFER in the JCL should (if I remember correctly) bypass the need for the recall and go direct to the uncatalog [which does not need a recall]. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
Why not run a small test with 10-15 datasets on 2-3 tape volumes? You may discover that your shop has some feature that prevents HSM from managing the tapes intelligently. :>: -Original Message- :>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :>: Behalf Of Lizette Koehler :>: Sent: Thursday, October 11, 2012 6:15 AM :>: To: IBM-MAIN@LISTSERV.UA.EDU :>: Subject: Re: DFHSM Recalls and Tape :>: :>: Everyone thanks so much for confirming what I was told. :>: :>: Where my problem arises is when a user wants to recall 5000 or more :>: datasets. I was concerned that the recall process would serialize it :>: rather :>: than finding all the files on a given migration tape and work with it :>: until :>: it needed a new tape. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
On Thu, 11 Oct 2012 10:19:59 -0400, O'Brien, David W. (NIH/CIT) [C] wrote: >I think you missed the distinction between submitting recalls and a process >causing recalls. At this shop it was not unusual for a user to submit an >Iefbr14 job to delete datasets thereby causing the recall of any dataset that >had been migrated. Since the recall is serial, it would result in one tape >mount per recall. Agreed that I missed that distinction. I agree there is ONE mount per recall. But I will stay with what I said about the problem of handling a lot of recalls requests and subsequent mounts. I think the IEFBR14 recall problem has been fixed in the last 5 years or so. AFAIK it is a setting in ALLOCxx member. Thanks Dave! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
Thanks Allan, the norecall option is specified in our ALLOxx member. I did use the past tense in my posting. There are however other processes that do the same thing here with the same redundant HSM tape mounts. I was just using Iefbr14 as an example that all would be familiar with. Dave O'Brien -Original Message- From: Staller, Allan [mailto:allan.stal...@kbmg.com] Sent: Thursday, October 11, 2012 10:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM Recalls and Tape See ' SYSTEM IEFBR14_DELMIGDS(NORECALL)' in SYS1.PARMLIB(ALLOCxx). New with z/OS 1.11 (?) At this shop it was not unusual for a user to submit an Iefbr14 job to delete datasets thereby causing the recall of any dataset that had been migrated. Since the recall is serial, it would result in one tape mount per recall. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
See ' SYSTEM IEFBR14_DELMIGDS(NORECALL)' in SYS1.PARMLIB(ALLOCxx). New with z/OS 1.11 (?) At this shop it was not unusual for a user to submit an Iefbr14 job to delete datasets thereby causing the recall of any dataset that had been migrated. Since the recall is serial, it would result in one tape mount per recall. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
Elardus, I think you missed the distinction between submitting recalls and a process causing recalls. At this shop it was not unusual for a user to submit an Iefbr14 job to delete datasets thereby causing the recall of any dataset that had been migrated. Since the recall is serial, it would result in one tape mount per recall. Dave O'Brien -Original Message- From: Elardus Engelbrecht [mailto:elardus.engelbre...@sita.co.za] Sent: Thursday, October 11, 2012 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM Recalls and Tape O'Brien, David W. wrote: >One caveat, if I may. Is your user submitting 5000 Hrecalls or are they >submitting a process which will result in 5000 recalls? The latter could >result in 5000 tape mounts. No. Look up on TAPEMAXRECALLTASKS and MAXRECALLTASKS. So in your example with TAPEMAXRECALLTASKS(10) you will use 10 tape mounts at a stage, not 5000 mounts. But yes, if all those datasets are residing on 5000 tapes, this is going to be a looong wait and very tired [1] ops. ;-) Lizette: You can have your mounts split up on several LPARS to spread out workload. Say 10 mounts on LPAR1, 20 mounts on LPAR2, etc. Check out the CRQ function of HSM. HTH! Groete / Greetings Elardus Engelbrecht [1] - Since we got a robot, incorrect mounts disappeared... unless you get a x13 or x14 abend. Then these ops eject it, INIT it and re-mount it with disastrous results! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
O'Brien, David W. wrote: >One caveat, if I may. Is your user submitting 5000 Hrecalls or are they >submitting a process which will result in 5000 recalls? The latter could >result in 5000 tape mounts. No. Look up on TAPEMAXRECALLTASKS and MAXRECALLTASKS. So in your example with TAPEMAXRECALLTASKS(10) you will use 10 tape mounts at a stage, not 5000 mounts. But yes, if all those datasets are residing on 5000 tapes, this is going to be a looong wait and very tired [1] ops. ;-) Lizette: You can have your mounts split up on several LPARS to spread out workload. Say 10 mounts on LPAR1, 20 mounts on LPAR2, etc. Check out the CRQ function of HSM. HTH! Groete / Greetings Elardus Engelbrecht [1] - Since we got a robot, incorrect mounts disappeared... unless you get a x13 or x14 abend. Then these ops eject it, INIT it and re-mount it with disastrous results! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
They are using a REXX that generates HRECALL (file1 file2 file3 file4 etc...) NOWAIT Or some will submit a TSO Batch job with individual HRECALL file1 NOWAIT commands. I am not happy with this process and am I working to create a better REXX for them to use for this. But for now, we have requested that if they have over 1000 recalls to be done, to let my group work on them. The rewrite is that the command to HSM to alter priority for that userid will also be done at the end of the HRECALL requests. That way I can at least place them at the bottom of the priority and let other HSM RECALLS happen as they come into the queue. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf > Of O'Brien, David W. (NIH/CIT) [C] > > Lizette, > > One caveat, if I may. Is your user submitting 5000 Hrecalls or are they submitting a > process which will result in 5000 recalls? The latter could result in 5000 tape mounts. > > Dave O'Brien > > -Original Message- > From: Lizette Koehler [mailto:stars...@mindspring.com] > Sent: Thursday, October 11, 2012 9:15 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM Recalls and Tape > > Everyone thanks so much for confirming what I was told. > > Where my problem arises is when a user wants to recall 5000 or more datasets. I was > concerned that the recall process would serialize it rather than finding all the files on a > given migration tape and work with it until it needed a new tape. > > Very helpful > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On > Behalf > > Of O'Brien, David W. (NIH/CIT) [C] > > > > Hervey, > > > > That is not true, at least not at this shop. HSM routinely queues > > recalls > according to > > tape volume in order to minimize tape mounts with or without CRQ. > > > > Dave O'Brien > > > > -Original Message- > > From: Hervey Martinez [mailto:hervey.marti...@custserv.com] > > Sent: Thursday, October 11, 2012 7:55 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: DFHSM Recalls and Tape > > > > If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead" > and recall > > all files that are on the same tape. Also, with CRQ, you can limit > > which > LPARS will > > perform recalls and limit them in that manner and all recalls will be > routed to that > > LPAR. Otherwise, the recalls happen one at a time in a FIFO manner. > > > > Regards, > > > > Hervey > > > > -Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On > Behalf > > Of Robert A. Rosenberg > > Sent: Thursday, October 11, 2012 3:58 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: DFHSM Recalls and Tape > > > > At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM > > Recalls > and > > Tape: > > > > >When it HSM finishes a recall, it checks the que in order for any > > >recall on the same tape. When it reaches the end of the que, it > > >unmounts the tape, and starts recalling the first waiting dataset on > > >the que. Haven't done as massive a quantity as 10,000 though. > > > > > >No sorting of any kind, just checking the que DSN against the list on > > >the mounted tape. > > > > So you are saying that as it reads the tape (after it has recalled a > > file > from the tape) it > > sees the next file on the tape and checks if it is on the queue. It > > then > either recalls the > > file (if it is on the > > queue) or reads the tape to the next file and does the queue check again. > > > > From your "no sort" comment, I assume that it does not order the > > queue > based on > > restore tape volume but just runs the full queue until it finds the > dataset name or > > reaches the end of the queue. If the latter it seems inefficient since > > if > the queue was > > ordered by volume serial number it could stop the scan once it reached > > an > entry on a > > different tape. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
Hervey, Yes I do have CRQ in use. I am also working to implementing MASH (Multiple Address Space HSM) and RLS to try and provide some performance and relief to DFHSM Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf > Of Hervey Martinez > Sent: Thursday, October 11, 2012 6:08 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM Recalls and Tape > > Dave, > > Yes I've heard that but have never seen it done without CRQ. > > Regards, > > Hervey > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf > Of O'Brien, David W. (NIH/CIT) [C] > Sent: Thursday, October 11, 2012 8:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM Recalls and Tape > > Hervey, > > That is not true, at least not at this shop. HSM routinely queues recalls according to > tape volume in order to minimize tape mounts with or without CRQ. > > Dave O'Brien > > -Original Message- > From: Hervey Martinez [mailto:hervey.marti...@custserv.com] > Sent: Thursday, October 11, 2012 7:55 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM Recalls and Tape > > If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead" and recall > all files that are on the same tape. Also, with CRQ, you can limit which LPARS will > perform recalls and limit them in that manner and all recalls will be routed to that > LPAR. Otherwise, the recalls happen one at a time in a FIFO manner. > > Regards, > > Hervey > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf > Of Robert A. Rosenberg > Sent: Thursday, October 11, 2012 3:58 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM Recalls and Tape > > At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM Recalls and > Tape: > > >When it HSM finishes a recall, it checks the que in order for any > >recall on the same tape. When it reaches the end of the que, it > >unmounts the tape, and starts recalling the first waiting dataset on > >the que. Haven't done as massive a quantity as 10,000 though. > > > >No sorting of any kind, just checking the que DSN against the list on > >the mounted tape. > > So you are saying that as it reads the tape (after it has recalled a file from the tape) it > sees the next file on the tape and checks if it is on the queue. It then either recalls the > file (if it is on the > queue) or reads the tape to the next file and does the queue check again. > > From your "no sort" comment, I assume that it does not order the queue based on > restore tape volume but just runs the full queue until it finds the dataset name or > reaches the end of the queue. If the latter it seems inefficient since if the queue was > ordered by volume serial number it could stop the scan once it reached an entry on a > different tape. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
Lizette, One caveat, if I may. Is your user submitting 5000 Hrecalls or are they submitting a process which will result in 5000 recalls? The latter could result in 5000 tape mounts. Dave O'Brien -Original Message- From: Lizette Koehler [mailto:stars...@mindspring.com] Sent: Thursday, October 11, 2012 9:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM Recalls and Tape Everyone thanks so much for confirming what I was told. Where my problem arises is when a user wants to recall 5000 or more datasets. I was concerned that the recall process would serialize it rather than finding all the files on a given migration tape and work with it until it needed a new tape. Very helpful Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf > Of O'Brien, David W. (NIH/CIT) [C] > > Hervey, > > That is not true, at least not at this shop. HSM routinely queues > recalls according to > tape volume in order to minimize tape mounts with or without CRQ. > > Dave O'Brien > > -Original Message- > From: Hervey Martinez [mailto:hervey.marti...@custserv.com] > Sent: Thursday, October 11, 2012 7:55 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM Recalls and Tape > > If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead" and recall > all files that are on the same tape. Also, with CRQ, you can limit > which LPARS will > perform recalls and limit them in that manner and all recalls will be routed to that > LPAR. Otherwise, the recalls happen one at a time in a FIFO manner. > > Regards, > > Hervey > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf > Of Robert A. Rosenberg > Sent: Thursday, October 11, 2012 3:58 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM Recalls and Tape > > At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM > Recalls and > Tape: > > >When it HSM finishes a recall, it checks the que in order for any > >recall on the same tape. When it reaches the end of the que, it > >unmounts the tape, and starts recalling the first waiting dataset on > >the que. Haven't done as massive a quantity as 10,000 though. > > > >No sorting of any kind, just checking the que DSN against the list on > >the mounted tape. > > So you are saying that as it reads the tape (after it has recalled a > file from the tape) it > sees the next file on the tape and checks if it is on the queue. It > then either recalls the > file (if it is on the > queue) or reads the tape to the next file and does the queue check again. > > From your "no sort" comment, I assume that it does not order the > queue based on > restore tape volume but just runs the full queue until it finds the dataset name or > reaches the end of the queue. If the latter it seems inefficient since > if the queue was > ordered by volume serial number it could stop the scan once it reached > an entry on a > different tape. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
Everyone thanks so much for confirming what I was told. Where my problem arises is when a user wants to recall 5000 or more datasets. I was concerned that the recall process would serialize it rather than finding all the files on a given migration tape and work with it until it needed a new tape. Very helpful Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf > Of O'Brien, David W. (NIH/CIT) [C] > > Hervey, > > That is not true, at least not at this shop. HSM routinely queues recalls according to > tape volume in order to minimize tape mounts with or without CRQ. > > Dave O'Brien > > -Original Message- > From: Hervey Martinez [mailto:hervey.marti...@custserv.com] > Sent: Thursday, October 11, 2012 7:55 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM Recalls and Tape > > If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead" and recall > all files that are on the same tape. Also, with CRQ, you can limit which LPARS will > perform recalls and limit them in that manner and all recalls will be routed to that > LPAR. Otherwise, the recalls happen one at a time in a FIFO manner. > > Regards, > > Hervey > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf > Of Robert A. Rosenberg > Sent: Thursday, October 11, 2012 3:58 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM Recalls and Tape > > At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM Recalls and > Tape: > > >When it HSM finishes a recall, it checks the que in order for any > >recall on the same tape. When it reaches the end of the que, it > >unmounts the tape, and starts recalling the first waiting dataset on > >the que. Haven't done as massive a quantity as 10,000 though. > > > >No sorting of any kind, just checking the que DSN against the list on > >the mounted tape. > > So you are saying that as it reads the tape (after it has recalled a file from the tape) it > sees the next file on the tape and checks if it is on the queue. It then either recalls the > file (if it is on the > queue) or reads the tape to the next file and does the queue check again. > > From your "no sort" comment, I assume that it does not order the queue based on > restore tape volume but just runs the full queue until it finds the dataset name or > reaches the end of the queue. If the latter it seems inefficient since if the queue was > ordered by volume serial number it could stop the scan once it reached an entry on a > different tape. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
Dave, Yes I've heard that but have never seen it done without CRQ. Regards, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Thursday, October 11, 2012 8:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM Recalls and Tape Hervey, That is not true, at least not at this shop. HSM routinely queues recalls according to tape volume in order to minimize tape mounts with or without CRQ. Dave O'Brien -Original Message- From: Hervey Martinez [mailto:hervey.marti...@custserv.com] Sent: Thursday, October 11, 2012 7:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM Recalls and Tape If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead" and recall all files that are on the same tape. Also, with CRQ, you can limit which LPARS will perform recalls and limit them in that manner and all recalls will be routed to that LPAR. Otherwise, the recalls happen one at a time in a FIFO manner. Regards, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert A. Rosenberg Sent: Thursday, October 11, 2012 3:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM Recalls and Tape At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM Recalls and Tape: >When it HSM finishes a recall, it checks the que in order for any >recall on the same tape. When it reaches the end of the que, it >unmounts the tape, and starts recalling the first waiting dataset on >the que. Haven't done as massive a quantity as 10,000 though. > >No sorting of any kind, just checking the que DSN against the list on >the mounted tape. So you are saying that as it reads the tape (after it has recalled a file from the tape) it sees the next file on the tape and checks if it is on the queue. It then either recalls the file (if it is on the queue) or reads the tape to the next file and does the queue check again. From your "no sort" comment, I assume that it does not order the queue based on restore tape volume but just runs the full queue until it finds the dataset name or reaches the end of the queue. If the latter it seems inefficient since if the queue was ordered by volume serial number it could stop the scan once it reached an entry on a different tape. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
Hervey, That is not true, at least not at this shop. HSM routinely queues recalls according to tape volume in order to minimize tape mounts with or without CRQ. Dave O'Brien -Original Message- From: Hervey Martinez [mailto:hervey.marti...@custserv.com] Sent: Thursday, October 11, 2012 7:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM Recalls and Tape If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead" and recall all files that are on the same tape. Also, with CRQ, you can limit which LPARS will perform recalls and limit them in that manner and all recalls will be routed to that LPAR. Otherwise, the recalls happen one at a time in a FIFO manner. Regards, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert A. Rosenberg Sent: Thursday, October 11, 2012 3:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM Recalls and Tape At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM Recalls and Tape: >When it HSM finishes a recall, it checks the que in order for any >recall on the same tape. When it reaches the end of the que, it >unmounts the tape, and starts recalling the first waiting dataset on >the que. Haven't done as massive a quantity as 10,000 though. > >No sorting of any kind, just checking the que DSN against the list on >the mounted tape. So you are saying that as it reads the tape (after it has recalled a file from the tape) it sees the next file on the tape and checks if it is on the queue. It then either recalls the file (if it is on the queue) or reads the tape to the next file and does the queue check again. From your "no sort" comment, I assume that it does not order the queue based on restore tape volume but just runs the full queue until it finds the dataset name or reaches the end of the queue. If the latter it seems inefficient since if the queue was ordered by volume serial number it could stop the scan once it reached an entry on a different tape. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead" and recall all files that are on the same tape. Also, with CRQ, you can limit which LPARS will perform recalls and limit them in that manner and all recalls will be routed to that LPAR. Otherwise, the recalls happen one at a time in a FIFO manner. Regards, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert A. Rosenberg Sent: Thursday, October 11, 2012 3:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM Recalls and Tape At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM Recalls and Tape: >When it HSM finishes a recall, it checks the que in order for any >recall on the same tape. When it reaches the end of the que, it >unmounts the tape, and starts recalling the first waiting dataset on >the que. Haven't done as massive a quantity as 10,000 though. > >No sorting of any kind, just checking the que DSN against the list on >the mounted tape. So you are saying that as it reads the tape (after it has recalled a file from the tape) it sees the next file on the tape and checks if it is on the queue. It then either recalls the file (if it is on the queue) or reads the tape to the next file and does the queue check again. From your "no sort" comment, I assume that it does not order the queue based on restore tape volume but just runs the full queue until it finds the dataset name or reaches the end of the queue. If the latter it seems inefficient since if the queue was ordered by volume serial number it could stop the scan once it reached an entry on a different tape. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM Recalls and Tape: When it HSM finishes a recall, it checks the que in order for any recall on the same tape. When it reaches the end of the que, it unmounts the tape, and starts recalling the first waiting dataset on the que. Haven't done as massive a quantity as 10,000 though. No sorting of any kind, just checking the que DSN against the list on the mounted tape. So you are saying that as it reads the tape (after it has recalled a file from the tape) it sees the next file on the tape and checks if it is on the queue. It then either recalls the file (if it is on the queue) or reads the tape to the next file and does the queue check again. From your "no sort" comment, I assume that it does not order the queue based on restore tape volume but just runs the full queue until it finds the dataset name or reaches the end of the queue. If the latter it seems inefficient since if the queue was ordered by volume serial number it could stop the scan once it reached an entry on a different tape. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
When it HSM finishes a recall, it checks the que in order for any recall on the same tape. When it reaches the end of the que, it unmounts the tape, and starts recalling the first waiting dataset on the que. Haven't done as massive a quantity as 10,000 though. No sorting of any kind, just checking the que DSN against the list on the mounted tape. On Wed, Oct 10, 2012 at 5:27 PM, Lizette Koehler wrote: > Just want to make sure I understand what IBM told me once. > > Is it true that when you have a large number of recalls (and I am talking > 10,000 or more at a time) that HSM will identify which ones are on which > migration tapes and stack them accordingly. Or is it still a manual process > of identifying which datasets are on what migration tapes and doing the > recalls in tape volser bundle? > > For example I may have 3000 datasets on tape V00012. So I would pull a list > of datasets on that tape and then issue the recall for all of those files in > one recall bunch. > > Or could I recall all 10,000 files and HSM will recall the datasets all from > the same tape at one time and not do mount tape, unmount tape, mount tape, > unmount tape and so on. > > Thanks > > Lizette > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
On 10/10/2012 6:27 PM, Lizette Koehler wrote: Just want to make sure I understand what IBM told me once. Is it true that when you have a large number of recalls (and I am talking 10,000 or more at a time) that HSM will identify which ones are on which migration tapes and stack them accordingly. Or is it still a manual process of identifying which datasets are on what migration tapes and doing the recalls in tape volser bundle? For example I may have 3000 datasets on tape V00012. So I would pull a list of datasets on that tape and then issue the recall for all of those files in one recall bunch. Or could I recall all 10,000 files and HSM will recall the datasets all from the same tape at one time and not do mount tape, unmount tape, mount tape, unmount tape and so on. Thanks Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Lizette, It's upposed to work that way. Open a PMR if it doesn't. Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM Recalls and Tape
I understand and have experienced, DFHSM does indeed sort multiple (NOWAIT) requests such that tape mounts are minimized. Dave Gibney Information Technology Services Washington State University > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lizette Koehler > Sent: Wednesday, October 10, 2012 3:28 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM Recalls and Tape > > Just want to make sure I understand what IBM told me once. > > Is it true that when you have a large number of recalls (and I am talking > 10,000 or more at a time) that HSM will identify which ones are on which > migration tapes and stack them accordingly. Or is it still a manual process > of > identifying which datasets are on what migration tapes and doing the recalls > in tape volser bundle? > > For example I may have 3000 datasets on tape V00012. So I would pull a list > of datasets on that tape and then issue the recall for all of those files in > one > recall bunch. > > Or could I recall all 10,000 files and HSM will recall the datasets all from > the > same tape at one time and not do mount tape, unmount tape, mount tape, > unmount tape and so on. > > Thanks > > Lizette > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFHSM Recalls and Tape
Just want to make sure I understand what IBM told me once. Is it true that when you have a large number of recalls (and I am talking 10,000 or more at a time) that HSM will identify which ones are on which migration tapes and stack them accordingly. Or is it still a manual process of identifying which datasets are on what migration tapes and doing the recalls in tape volser bundle? For example I may have 3000 datasets on tape V00012. So I would pull a list of datasets on that tape and then issue the recall for all of those files in one recall bunch. Or could I recall all 10,000 files and HSM will recall the datasets all from the same tape at one time and not do mount tape, unmount tape, mount tape, unmount tape and so on. Thanks Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
