>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 1&2 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
