Longer save times after upgrade from v4r4 to v4r5

[Guest.Visitor]

What Cume PTF are you at? We applied C1198450 and it appears to have caused our save times to approximately double! Anyone else experienced this?

[dbrunner@co.kenosha.wi.us]

Ken and Stephen, I am considering loading the cume C1198450, but now you have me scared. Can you confirm that this is the problem child? The upgrade to V4R5 did not cause any problems to the backups under C1100450. Thanks, Dale

[Guest.Visitor]

Cannot confirm yet. I've opened a PMR with IBM, sent them some joblogs & such which merely allowed them to confirm that it did take twice as long to back up. I'm to get them some Flight Recorders from our next full Friday backup. FYI, I'm on a model 820, using a 2749 40MB/s SCSI card, and an OEM tape drive from BCC that emulates a 3570.

[wjminc]

Ken, What is the PMR number for the backup taking longer problem? We have planned to go to V4R5 this weekend. Should I go ahead and use the C1198450 cum or use C1100450. Thanks for the heads up on this problem. Willie..

[Guest.Visitor]

My PMR is 73703 227. However, the problem "went away" this previous weekend. There were only 3 changes I made: 1. Removed logging from commands. On the SAVLIB *ALLUSR, I was having it put error info to an outfile. Similarly for SAVDLO (though error-only isn't available) and SAV. I stopped doing that. 2. We had an abnormal IPL during last week (due to bogus signals from the UPS while testing the data connection). 3. During the IPL, about 6 MFxxxxx PTFs were applied. This coming Friday I'm going to put the logging parms back into the commands to see if that has any effect. It shouldn't; the backups went fine with logging before. So maybe it was the PTFs. For what it's worth, they were: MF26722 - extensions for maintenance MF26934 - Netserver MF27043 - Java MF27048 - job hangs during performance collection MF27064 - VPD reset failure MF27096 - COBOL compiler loop MF27101 - tape controller vary-on fails MF27113 - SRC1XXC9031-HLIC-94XXPWR Also, we are doing Save-While-Active, so that may have had something to do with it. I'd recommend going ahead with the upgrade on the current Cume, plus any HIPERs, and possibly the ones above that look the most suspicious. Good luck; we're going to V5R1 next Sunday....

[dbrunner@co.kenosha.wi.us]

Ken, Thanks for the update. My mind rests easier now. Good luck on your upgrade! Dale

[Guest.Visitor]

Sorry it took so long to get back to you on this. We are also on C1198450. Since we just went to v4r5, I can't comment on whether it was the release level upgrade or the cume level that's causing our problems. From your experience though, it does sound like the cume level is the culprit. We aren't using save-while-active and we also aren't logging to an outfile or print. We're doing SAVLIBs, SAVOBJs, SAVDLOs, SAVSECDTA and SAVCFG. It seems like the SAVLIBs are the only ones causing the problems, but that may be due to the amount of data being saved. We'll be going to V5R1 in a few months, so we may just have to live with it and hope it get's better at V5. Good luck with your upgrade. Let us know how it goes.

[Guest.Visitor]

When we went to V4R5 we had to same problem. It seams that IBM changed the default wait time for BATCH jobs so the system is wating longer to get locks on the files before it saves them. We changed our save CL to issue the CHGJOB command to change the default wait time and time slice and all is good.

[wjminc]

David, Where do I find what the current setting for wait time/time slice. We are going to v4r5 this weekend. Thanks, Willie...

[Guest.Visitor]

Wille, There is no SYSVAL or anything like that it's just automatic. I believe that it is 30 sec. If you "work with job" and select option 3 it will show the current wait time and time slice. When we upgrade a release we do a FULL system save before and after to before took 10 hours to after took 24 or more. Our nightly saves also doubled in time. Once we changed the default wait to 5 secs they now take half the time of the V4R4 saves. Dave