Re: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation
on 6/2/05 6:26 PM, Russell Witt at [EMAIL PROTECTED] wrote: > Of course there is always the Tape Preferencing and Control Facility (TPCF) > within the MIA component of Unicenter CA-MIM. That has a couple of different > options for controlling the allocation of shared tape drives (either > dedicate them to a single system, share, or assign a preference value). Just > another option.. > > Russell Witt > CA-1 Level-2 Support Manager --SNIP__ Thanks Russell, finally, a reason to use MIM:-) Ed -- 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: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation
Of course there is always the Tape Preferencing and Control Facility (TPCF) within the MIA component of Unicenter CA-MIM. That has a couple of different options for controlling the allocation of shared tape drives (either dedicate them to a single system, share, or assign a preference value). Just another option.. Russell Witt CA-1 Level-2 Support Manager -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Ted MacNEIL Sent: Wednesday, June 01, 2005 7:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation ... Using the lowest tape drive address is bad for tape drive wear and tear ... I was attempting to be sarcastic about the “thank-you”. And, you are correct. The algorithm is wrong. -- 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: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation
... Using the lowest tape drive address is bad for tape drive wear and tear ... I was attempting to be sarcastic about the “thank-you”. And, you are correct. The algorithm is wrong. [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: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation
on 6/1/05 7:00 PM, Ted MacNEIL at [EMAIL PROTECTED] wrote: > ... > If so, how to do tell z/OS to "spread the I/O" around? I used > to have SELTAPE=NEXT > ... > SELTAPE has gone the way of the Dodo. > The IEAOPTxx parm was dropped with ESA, IIRC. > > It is now the lowest available UCB, just like DASD allocations. > > Thank you, SMS! > > [EMAIL PROTECTED] > Ted, I guess I disagree (If I understand what you are cheering about).. Using the lowest tape drive address is bad for tape drive wear and tear. I won't go into a story as I don't want to be called for going off into off topic terratory. Ed -- 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: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation
... If so, how to do tell z/OS to "spread the I/O" around? I used to have SELTAPE=NEXT ... SELTAPE has gone the way of the Dodo. The IEAOPTxx parm was dropped with ESA, IIRC. It is now the lowest available UCB, just like DASD allocations. Thank you, SMS! [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: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation
Q1: I would argue that you are spending expensive CPU and sacrificing throughput to conserve DASD. As cheap as DASD is these days, perhaps the business case is to reduce/eliminate the need to do space management, reclaim that CPU, and generally speed up throughput. As to Q2: Generally speaking, I trust the perception of an experienced operator. But only so far. Perhaps the mix of work is causing higher numbered drives to be allocated but never actually used. Whichever, I would want some numbers from a trusted measuring tool. But, why does anyone care? Just my $0.02 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Wednesday, June 01, 2005 9:20 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation I know that asking two question is bad form. But I'm trying to "save a message slot". Both questions are about a z/OS 1.4 system. Q1: DFHSM CPU Utilization We are having a problem with DFHSM CPU utilization. It seems that no matter when we schedule PRIMARY SPACE MANAGEMENT, somebody complains. DFHSM runs as a high priority started task. This is so that recalls are handled quickly. I admit that I have not gone into the manuals yet. I'm am very pressed for time due to staff reductions . So, is it possible to have two DFHSM started tasks? One would be high priority for recalls, the other a lower priority for PRIMARY SPACE MANAGEMENT. I know very little of DFHSM. If possible, is it "easy" or "a pain"? Thanks. Q2: Tape Allocation. We have four banks of 3490E tape drives. Each bank contains 8 drives. Each bank is attached to two CHPs which are dedicated to that bank of drives. I have been told that the "low address" tape drives appear to be allocated in preference to the "high address" tape drives. I cannot guarantee that the operators are not "messing around" using a VARY, but I have been told that they are not. Also I haven't seen any VARY command in the SYSLOG. So I assume that I am being told the truth. In the past, there was a SELTAPE parameter which disappeared long ago. Does this reuse of "low addressed" tape drives sound like what is supposed to be happening? If so, how to do tell z/OS to "spread the I/O" around? I used to have SELTAPE=NEXT. Again, due to other demands on my time, I have not had a chance to double check that I'm being told the truth. But the guy who is telling me this is a "reputable source" as the news-droids say. Thanks. Oh - will z/OS 1.6 make any difference? We are supposed to go to it something 3rd Q. -- 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 -- 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: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation
John - It's my understanding that this is how allocation currently works and I don't know of anything in z/OS 1.6 that changes it. I believe that the STK allocation code is supposed to do this for tape drives in an STK tape library and perhaps for non-library drives as well, but I don't think that we ever confirmed that. Larre Shiller US Social Security Administration [EMAIL PROTECTED] V/M: (410) 965-2209 FAX: (410) 966-1936 www.ssa.gov "The contents of this message are mine personally and do not necessarily reflect any official position of the US Government or the US Social Security Administration." On Wed, 1 Jun 2005 09:19:45 -0500, McKown, John <[EMAIL PROTECTED]> wrote: >Q2: Tape Allocation. >We have four banks of 3490E tape drives. Each bank contains 8 drives. >Each bank is attached to two CHPs which are dedicated to that bank of >drives. I have been told that the "low address" tape drives appear to be >allocated in preference to the "high address" tape drives. I cannot >guarantee that the operators are not "messing around" using a VARY, but >I have been told that they are not. Also I haven't seen any VARY command >in the SYSLOG. So I assume that I am being told the truth. In the past, >there was a SELTAPE parameter which disappeared long ago. Does this >reuse of "low addressed" tape drives sound like what is supposed to be >happening? If so, how to do tell z/OS to "spread the I/O" around? I used >to have SELTAPE=NEXT. Again, due to other demands on my time, I have not >had a chance to double check that I'm being told the truth. But the guy >who is telling me this is a "reputable source" as the news-droids say. > > >Thanks. Oh - will z/OS 1.6 make any difference? We are supposed to go to >it something 3rd Q. > > >-- >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: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation
We run DFHSM in two address spaces for this reason DFHSM and DFHSM#. Take a look at the HOSTMODE=AUX parameter and documentation. I classify the primary DFHSM in SYSSTC and the auxiliary DFHSM in STCLO to provide a service level roughly equivalent to production batch. We have not yet cutover to z/OS R6 yet but IIUC the only big changes in this area were to allow for MORE (nee ANY) multi-tasking in Secondary Space Management. From my student notebook "SETSYS MAXSSMTASKS allows you to set multi-tasking on for two parts of SSm - the migration function and the cleanup function. Note although there is multiple threaded migration from ML1 to ML2, there is still only one task used for ML1-to-ML2 DASD data movement.". Thanks, Sam -Original Message- Q1: DFHSM CPU Utilization We are having a problem with DFHSM CPU utilization. It seems that no matter when we schedule PRIMARY SPACE MANAGEMENT, somebody complains. DFHSM runs as a high priority started task. This is so that recalls are handled quickly. I admit that I have not gone into the manuals yet. I'm am very pressed for time due to staff reductions . So, is it possible to have two DFHSM started tasks? One would be high priority for recalls, the other a lower priority for PRIMARY SPACE MANAGEMENT. I know very little of DFHSM. If possible, is it "easy" or "a pain"? Thanks. <> This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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
