Re: Too many ALTERs?
In [EMAIL PROTECTED], on 09/07/2006 at 10:50 AM, Terry BRuns [EMAIL PROTECTED] said: I was really looking for affirmation that running TSO ALTER commands in batch was the cause of their performance issue It's certainly more overhead than doing all of them in a single invocation of AMS. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Too many ALTERs?
Here's a weird one. The Storage folks where I work run batches of ALTERs to change Storage and Management classes for SMS managed data sets. Their current procedure calls for saving a list of data sets in ISPF 3.4, then editing the resultant list into ALTER control cards. One of them asked me to come up with a REXX exec to help create the control cards, because it was hard when the list was thousands of data sets long. But then she told me I had to keep each job down to 30 or less ALTERs because any more would bog the system down. Upon further investigation, I found that the batch job they use is actually batch TSO, not IDCAMS. I'm suspecting that using the ALTER TSO command under batch TSO may be the reason for the bogging and that using IDCAMS would produce different results as far as performance is concerned. Does anyone have any thoughts on this? Have any of you run into performance degradation when running too many ALTERs? Suggestion #1 - you can find on the CBT tape a number of TSOCP's which do a WAIT for a number of seconds, see file 300, PGM=DELAY. The programmer can introduce this command every 30 Alters or so with a delay some seconds so processing can catchup. This makes the gludge more gludgey. Suggestion #2 - change the format of the alter to IDCAMS control cards and run using IDCAMS. note: a less gludey approach. Suggstion #3 - look at the SMS routines to minimize why 12 would even be necessary. Jim -- 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: Too many ALTERs?
Sure, I'd do things differently with their ACS routines, but I'm just a consultant and nobody here asked me to stick my nose into their Storage Management! You can address it as part of the resource/system contention issue that they asked you to look into. The only time they should be doing mass ALTERs is if they change the classification of something. When in doubt. PANIC!! -- 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: Too many ALTERs?
Does anyone have any thoughts on this? Have any of you run into performance degradation when running too many ALTERs? The real question should be: Why are they running enough ALTERs for this to be an issue? There has to be something drastically wrong with the ACS routines if you are running enough ALTERs to discover a performance issue. Why don't they just fix the routines? When in doubt. PANIC!! -- 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: Too many ALTERs?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Wednesday, September 06, 2006 3:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Too many ALTERs? Does anyone have any thoughts on this? Have any of you run into performance degradation when running too many ALTERs? The real question should be: Why are they running enough ALTERs for this to be an issue? There has to be something drastically wrong with the ACS routines if you are running enough ALTERs to discover a performance issue. Why don't they just fix the routines? When in doubt. PANIC!! Change in management philosophy for those datasets? Of course, I'd likely see if just changing the actual management class would be sufficient. But, then again, perhaps they are creating brand new management and storage classes and want the existing datasets to have the correct values based on the new criteria. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group 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
