Re: HSM recall on one LPAR for request on another lpar
In a message dated 7/16/2008 6:29:53 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: What is the risk? One possible risk is that the sandbox LPAR can crash while holding a reserve done by HSM, which then locks up some process on the prod LPAR. I crashed a test system once while it held a reserve on the JES2 checkpoint data set which caused the prod system's JES2 to get very unhappy. Bill Fairchild Rocket Software **Get the scoop on last night's hottest shows and the live music scene in your area - Check out TourTracker.com! (http://www.tourtracker.com?NCID=aolmus0005000112) -- 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: HSM recall on one LPAR for request on another lpar
John, I have 3 LPAR's participating in a HSMPlex. My 'batch' prod LPAR does all the HSM work (Migration, Backups, Recycles, Expirebv etc). The other 2 LPARs only allow Recalls and Recovers. No problems have been reported for the past 3 years with this setup. From: John Mattson [mailto:[EMAIL PROTECTED] Sent: Thu 7/17/2008 12:39 AM To: IBM-MAIN@BAMA.UA.EDU Subject: HSM recall on one LPAR for request on another lpar No sysplex, Each is a MONOPLEX, and GRS ring is active, all DASD shared. Anyone see any possible downside to having the sandbox lpar do RECALL's only? -- 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: HSM recall on one LPAR for request on another lpar
On Wed, 16 Jul 2008 23:29:24 +, Ted MacNEIL wrote: I only run HSM on my prod LPAR because I do not want to risk sharing HSM data with my sandbox. What is the risk? Are they in the same SYSPLEX? In our case, not risk, but inaccessibility of drives. So occasionally during testing on LPAR:TEST I have to recall something, and of course, it fails since there is no HSM on that LPAR. So I go over to the Prod LPAR, recall the DS, go back to TEST and REPLY CONTINUE, and I get another HSM message. Even tho the data set is now recalled, I have to cancel and restart the job. Is there a way around this? Me, too. This ought to be APARable. Of course it's WAD, but it's a bad design. There's a clear objective that's not being met. There's a similar problem when allocation asks me to select an offline unit from among a list when all other suitable units are busy. I know that no offline unit is suitable (they're offline for a reason). So I wait until another job completes and frees a unit. But the allocation WTO won't accept that unit; it insists on one from the list it presented earlier. The environment changes, quite dynamically, but in these two cases the logic driving the WTO is impaired by a static tunnel vision. -- gil -- 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: HSM recall on one LPAR for request on another lpar
Having a sysplex member with no access to tape drives is a perfect environment for HSM Common Recall Queue, where some other member(s) perform ML2 recalls on behalf of other systems. We generally run the Common Queue everywhere just to spread the work among members. But we recently built a new sysplex member that did not have tape for a few weeks. In the meantime, recalls were performed by other members in a perfectly seamless manner. As a TSO user, for example, you would never know that a data set was actually being recalled by another system. Same messages, just as fast. You do have to have a parallel sysplex for a shared CF structure. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Paul Gilmartin [EMAIL PROTECTED] .COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: HSM recall on one LPAR for request on another lpar 07/17/2008 10:21 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU On Wed, 16 Jul 2008 23:29:24 +, Ted MacNEIL wrote: I only run HSM on my prod LPAR because I do not want to risk sharing HSM data with my sandbox. What is the risk? Are they in the same SYSPLEX? In our case, not risk, but inaccessibility of drives. So occasionally during testing on LPAR:TEST I have to recall something, and of course, it fails since there is no HSM on that LPAR. So I go over to the Prod LPAR, recall the DS, go back to TEST and REPLY CONTINUE, and I get another HSM message. Even tho the data set is now recalled, I have to cancel and restart the job. Is there a way around this? Me, too. This ought to be APARable. Of course it's WAD, but it's a bad design. There's a clear objective that's not being met. There's a similar problem when allocation asks me to select an offline unit from among a list when all other suitable units are busy. I know that no offline unit is suitable (they're offline for a reason). So I wait until another job completes and frees a unit. But the allocation WTO won't accept that unit; it insists on one from the list it presented earlier. The environment changes, quite dynamically, but in these two cases the logic driving the WTO is impaired by a static tunnel vision. -- gil -- 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
HSM recall on one LPAR for request on another lpar
I only run HSM on my prod LPAR because I do not want to risk sharing HSM data with my sandbox. So occasionally during testing on LPAR:TEST I have to recall something, and of course, it fails since there is no HSM on that LPAR. So I go over to the Prod LPAR, recall the DS, go back to TEST and REPLY CONTINUE, and I get another HSM message. Even tho the data set is now recalled, I have to cancel and restart the job. Is there a way around this? -- 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: HSM recall on one LPAR for request on another lpar
I only run HSM on my prod LPAR because I do not want to risk sharing HSM data with my sandbox. What is the risk? Are they in the same SYSPLEX? So occasionally during testing on LPAR:TEST I have to recall something, and of course, it fails since there is no HSM on that LPAR. So I go over to the Prod LPAR, recall the DS, go back to TEST and REPLY CONTINUE, and I get another HSM message. Even tho the data set is now recalled, I have to cancel and restart the job. Is there a way around this? That process is always going to cause the error. My suggestion (done in the past) is to put up an HSM on the test LPAR, but not let it do any archiving/back-up; just recalls. Otherwise, continue with what you're doing. - Too busy driving to stop for gas! -- 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
HSM recall on one LPAR for request on another lpar
No sysplex, Each is a MONOPLEX, and GRS ring is active, all DASD shared. Anyone see any possible downside to having the sandbox lpar do RECALL's only? -- 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
