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
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
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
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, 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
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, 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
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
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
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
See ' SYSTEM IEFBR14_DELMIGDS(NORECALL)' in SYS1.PARMLIB(ALLOCxx). New with z/OS 1.11 (?) snip 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. /snip -- 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] obrie...@mail.nih.gov 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
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
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
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
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
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 stars...@mindspring.com 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
