Re: Question on DFHSM
A programmer works on a project. There are a lot of test datasets generated while he is doing this. The programmer gets pulled off of the project for over a month to work on something else. Now, he has to go back to work on the interrupted project. All the test datasets have been migrated. He wants to get all of the back as part of his restarting to avoid delays later. Note that this can be recursive. And, this is different from other shops? How? -teD Me? A skeptic? I trust you have proof! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
HSEND requires special authority. Instead use HRECALL, e.g., HRECALL dataset1 -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
In a recent note, Bruce Black said: Date: Wed, 21 Dec 2005 14:31:00 -0500 HSEND requires special authority. Instead use HRECALL, e.g., HRECALL dataset1 We both forgot to remind him (as if it were necessary), Don't specify WAIT. ENTREPRENURIAL He needs a robotic tape library. /ENTREPRENURIAL -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
Thanks Bruce, that did it. Rex -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
Gil, HSEND is short for HSENDCMD which is a generic front-end that apparently allows authorized users the ability to send any HSM command. Being that DFHSM is a VERY small hat I wear, I honestly didn't know about the HRECALL command - the DFHSM storage admin reference talks about RECALL but not HRECALL. What I failed to mention in my original post was that the programmer attempted to run a huge IEFBR14 job that had all 254 datasets in DD statements. The job sequentially went through the list of DD's, requesting a tape mount to recall a dataset, then moving on to the next one. Using IEBGENER will operate sequentially just as IEFBR14 does. As far as the Rexx exec, first of all my Rexx skills are sorely lacking (OK, non-existent, despite the namesake) and second, putting the recalls into the batch job passing the HRECALL requests to DFHSM is plenty fast enough. Bruce Black beat you to it, but the HRECALL worked just great - so thanks also for the suggestion. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Wednesday, December 21, 2005 1:41 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Question on DFHSM In a recent note, Pommier, Rex R. said: Date: Wed, 21 Dec 2005 13:24:00 -0600 //SYSTSIN DD * HSEND RECALL DATASET.ONE I always just use HRECALL DATASET.ONE ..., usually from DSLIST. What's HSEND? Will HRECALL work for the user? ARC1001I RECALL DATASET.ONE COMMAND FAILED, ARC1001I (CONT.) RC=0004, REAS= ARC1604I COMMAND NOT AUTHORIZED FOR USER As a last resort, how about EXEC PGM=IEBGENER with DD statements for all the data sets. Or will that also operate sequentially? Hmmm. For greatest concurrency, a Rexx exec that does SYSCALL spawn of a process that does BPXWDYN( 'alloc ...' ) for each data set? -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
Just FYI ... we've been using a program called RECALL from the CBTTAPE ... we put it in the first step of a job and it figures out what to recall ... and seems to do it with minimal tape mounts (although, I wouldn't really know that because all of our HSM tapes are in a 3494 robot -- so if it does lots of extra mounts, it won't complain). -- Stephen Pommier, Rex R. wrote: Gil, HSEND is short for HSENDCMD which is a generic front-end that apparently allows authorized users the ability to send any HSM command. Being that DFHSM is a VERY small hat I wear, I honestly didn't know about the HRECALL command - the DFHSM storage admin reference talks about RECALL but not HRECALL. What I failed to mention in my original post was that the programmer attempted to run a huge IEFBR14 job that had all 254 datasets in DD statements. The job sequentially went through the list of DD's, requesting a tape mount to recall a dataset, then moving on to the next one. Using IEBGENER will operate sequentially just as IEFBR14 does. As far as the Rexx exec, first of all my Rexx skills are sorely lacking (OK, non-existent, despite the namesake) and second, putting the recalls into the batch job passing the HRECALL requests to DFHSM is plenty fast enough. Bruce Black beat you to it, but the HRECALL worked just great - so thanks also for the suggestion. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Wednesday, December 21, 2005 1:41 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Question on DFHSM In a recent note, Pommier, Rex R. said: Date: Wed, 21 Dec 2005 13:24:00 -0600 //SYSTSIN DD * HSEND RECALL DATASET.ONE I always just use HRECALL DATASET.ONE ..., usually from DSLIST. What's HSEND? Will HRECALL work for the user? ARC1001I RECALL DATASET.ONE COMMAND FAILED, ARC1001I (CONT.) RC=0004, REAS= ARC1604I COMMAND NOT AUTHORIZED FOR USER As a last resort, how about EXEC PGM=IEBGENER with DD statements for all the data sets. Or will that also operate sequentially? Hmmm. For greatest concurrency, a Rexx exec that does SYSCALL spawn of a process that does BPXWDYN( 'alloc ...' ) for each data set? -- gil -- -- --- Stephen Y. Odo Senior Systems Programmerphone: (808)956-2383 Information Technology Services FAX: (808)956-2412 University of Hawai'ie-mail: [EMAIL PROTECTED] ... Region Registrar home phone: (808)847-1076 American Youth Soccer Organization Honolulu Region 178 e-mail: [EMAIL PROTECTED] --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
Rex, you've got the solution by now, but allow me some questions ... Why is the user wanting to recall all these datasets from migration? Is there a legitimate production requirement? If the datasets are used regularly, shouldn't they be online? Or should there be rules in place to retain these datasets on-line or in ML1 for a longer period? Or is the user trying to circumvent your established data retention / migration policies? (in this case a trip behind the woodshed might be in order ;-) Regards, Ulrich Krueger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
In a recent note, Stephen Y Odo said: Date: Wed, 21 Dec 2005 10:28:37 -1000 Just FYI ... we've been using a program called RECALL from the CBTTAPE ... we put it in the first step of a job and it figures out what to recall ... and seems to do it with minimal tape mounts (although, I wouldn't really know that because all of our HSM tapes are in a 3494 robot -- so if it does lots of extra mounts, it won't complain). Will JES3 perform recalls as part of job setup? Will the recalls be concurrent? (I could test this; I'm just lazy.) Pommier, Rex R. wrote: HSEND is short for HSENDCMD which is a generic front-end that apparently allows authorized users the ability to send any HSM command. Being that DFHSM is a VERY small hat I wear, I honestly didn't know about the HRECALL command - the DFHSM storage admin reference talks about RECALL but not HRECALL. It was my first suggestion, and Bruce's only. HRECALL is probably (I haven't verified) in the TSO manual. What I failed to mention in my original post was that the programmer attempted to run a huge IEFBR14 job that had all 254 datasets in DD statements. The job sequentially went through the list of DD's, requesting a tape mount to recall a dataset, then moving on to the next one. Using IEBGENER will operate sequentially just as IEFBR14 does. Lapsus mentis. I should have said IEFBR14. And I mentioned that feared the behavior you observed, which is why I went on to more bizarre suggestions; post-last-resort. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
Why is the user wanting to recall all these datasets from migration? Is there a legitimate production requirement? Excellent question. The best recall is one that is never done. Datasets should not be migrated (archived for ABR users) if they are likely to be recalled. If this user needs to recall a lot of datasets on a regular basis, you should review your criteria to see if you can avoid migrating them in the first place. If you use SMS to control migration, consider assigning these datasets to a different managemnet class that will prevent or delay their migration. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
I was wondering if anybody would question why my programmer is doing this. We are attempting to populate a data warehouse with everything including the kitchen sink - as well as all the kitchen sinks we have used in the past 8 years so he is recalling old, very old, and ancient generations of month-end, quarter-end, year-end data that we thought had been permanently mothballed to the confines of ML2. Many of these datasets haven't been accessed in years. So to answer your questions, yes the migration is working as it should be - including DFHSM scrambling to maintain some semblance of order with all these datasets migrating back to DASD. So no trip to the woodshed for the programmer - lucky for him. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Krueger Sent: Wednesday, December 21, 2005 2:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Question on DFHSM Rex, you've got the solution by now, but allow me some questions ... Why is the user wanting to recall all these datasets from migration? Is there a legitimate production requirement? If the datasets are used regularly, shouldn't they be online? Or should there be rules in place to retain these datasets on-line or in ML1 for a longer period? Or is the user trying to circumvent your established data retention / migration policies? (in this case a trip behind the woodshed might be in order ;-) Regards, Ulrich Krueger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Krueger Sent: Wednesday, December 21, 2005 2:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Question on DFHSM Rex, you've got the solution by now, but allow me some questions ... Why is the user wanting to recall all these datasets from migration? Is there a legitimate production requirement? If the datasets are used regularly, shouldn't they be online? Or should there be rules in place to retain these datasets on-line or in ML1 for a longer period? Or is the user trying to circumvent your established data retention / migration policies? (in this case a trip behind the woodshed might be in order ;-) Regards, Ulrich Krueger Perhaps it is like our shop. A programmer works on a project. There are a lot of test datasets generated while he is doing this. The programmer gets pulled off of the project for over a month to work on something else. Now, he has to go back to work on the interrupted project. All the test datasets have been migrated. He wants to get all of the back as part of his restarting to avoid delays later. Note that this can be recursive. I.e. working on project 1, pulled off to work on project 2, pulled off to work on project 3, restart work on project 2, restart work on project 1. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
Ah, that explains it! To expedite all those extra recalls and to make the processes run as fast as possible, I assume, you have already checked your DFHSM SETSYS parameters MAXRECALLTASKS and TAPEMAXRECALLTASKS and, if necessary, increased the numbers to either the IBM maximum or the max number of tape drives you can allow DFHSM to use without impacting other production jobs, haven't you? Of course, if you're really having a massive recall effort, I would probably have tried to figure out a way to submit the recall requests in order by ML2 VOLSER, to minimize / optimize tape mounts in DFHSM. Regards, Ulrich Krueger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
I know this might have already been answered but just want to throw in another idea. If I am reading this right the operators are complaining because they are mounting the same tape over and over? Why not use the mount command M (driveid),VOL=(SL,XX) the tape will stay mounted in what ever drive they select until they eject it. James H. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pommier, Rex R. Sent: Wednesday, December 21, 2005 1:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Question on DFHSM I know this is an easy question but I haven't been able to find the answer in the fine manuals - obviously I'm looking in the wrong place. I have a programmer that I want to give access to the HSM RECALL command. If this person submits a job that needs a migrated dataset, DFHSM brings the dataset back without question and his job runs. However, this guy wants to get at upwards of 200+ migrated datasets in the same job. The operators aren't happy mounting a DFHSM tape multiple times to get these datasets back. I gave him a job that will request multiple migrated datasets all at once like below: //LISTEXEC PGM=IKJEFT01,REGION=4096K //SYSTSPRT DD SYSOUT=X //SYSPRINT DD SYSOUT=X //SYSTSIN DD * HSEND RECALL DATASET.ONE HSEND RECALL DATASET.TWO HSEND RECALL DATASET.THREE This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
Actually it seems to me that DFHSM does sort the recall requests in order on my behalf. When the programmer was single-threading them with his infamous IEFBR14 job with the 250+ DD cards, DFHSM was doing a tape mount for every recall. When I put the 200+ datasets that hadn't been recalled yet into a single batch run with all the RECALL statements, DFHSM mounted a tape and recalled all the requested datasets on that tape then went to the next one. With only having 4 tape drives, I can't really set the TAPEMAXRECALLTASKS too high. It is set at 2 and if I were to try to make it any higher the operators would be all over me. Under normal circumstances (whatever 'normal' is) this works just fine. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Krueger Sent: Wednesday, December 21, 2005 3:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Question on DFHSM Ah, that explains it! To expedite all those extra recalls and to make the processes run as fast as possible, I assume, you have already checked your DFHSM SETSYS parameters MAXRECALLTASKS and TAPEMAXRECALLTASKS and, if necessary, increased the numbers to either the IBM maximum or the max number of tape drives you can allow DFHSM to use without impacting other production jobs, haven't you? Of course, if you're really having a massive recall effort, I would probably have tried to figure out a way to submit the recall requests in order by ML2 VOLSER, to minimize / optimize tape mounts in DFHSM. Regards, Ulrich Krueger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
Easy answer - 4 tape drives, 25 DFHSM tapes, datasets to be recalled scattered over all the tapes. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Huckert, James Sent: Wednesday, December 21, 2005 3:31 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Question on DFHSM I know this might have already been answered but just want to throw in another idea. If I am reading this right the operators are complaining because they are mounting the same tape over and over? Why not use the mount command M (driveid),VOL=(SL,XX) the tape will stay mounted in what ever drive they select until they eject it. James H. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pommier, Rex R. Sent: Wednesday, December 21, 2005 1:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Question on DFHSM I know this is an easy question but I haven't been able to find the answer in the fine manuals - obviously I'm looking in the wrong place. I have a programmer that I want to give access to the HSM RECALL command. If this person submits a job that needs a migrated dataset, DFHSM brings the dataset back without question and his job runs. However, this guy wants to get at upwards of 200+ migrated datasets in the same job. The operators aren't happy mounting a DFHSM tape multiple times to get these datasets back. I gave him a job that will request multiple migrated datasets all at once like below: //LISTEXEC PGM=IKJEFT01,REGION=4096K //SYSTSPRT DD SYSOUT=X //SYSPRINT DD SYSOUT=X //SYSTSIN DD * HSEND RECALL DATASET.ONE HSEND RECALL DATASET.TWO HSEND RECALL DATASET.THREE This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on DFHSM
Ah, that will do it every time. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pommier, Rex R. Sent: Wednesday, December 21, 2005 3:47 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Question on DFHSM Easy answer - 4 tape drives, 25 DFHSM tapes, datasets to be recalled scattered over all the tapes. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Huckert, James Sent: Wednesday, December 21, 2005 3:31 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Question on DFHSM I know this might have already been answered but just want to throw in another idea. If I am reading this right the operators are complaining because they are mounting the same tape over and over? Why not use the mount command M (driveid),VOL=(SL,XX) the tape will stay mounted in what ever drive they select until they eject it. This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
