We have recently run into a very odd performance problem with Sterling Commerce's CONNECT:Direct (aka NDM). We've opened a problem ticket on this but I'd like to see if any other users C:D users have seen anything similar.
Some time over the last 2 or 3 weeks we've seen a very large increase in the transmission times for some very large sequential datasets. Transmissions that used to take 20 minutes are now taking over 3 hours. This does not appear to be related to cycle availability at either end. For a while this problem was consistently related to our C:D on our production LPARs; the same transmission from a "development" LPAR ran at the old fast rate. Someone noticed that our we have checkpointing enabled by default on the prod C:Ds but not on the dev C:Ds so we turned it on on one of the dev C:Ds. Sure enough, the transmission rate took a nose dive. Unfortunately, turning checkpointing back off did not make the performance go back up. :-( Nothing changed in CONNECT:Direct in the past 3 weeks, but we did put some MVS (z/OS 1.8) maintenance on. (I don't know what maint.) To make things more puzzling, we have not had any obvious problem with our usual production transmissions. (This kind of increase SHOULD have been noticeable even if SLAs were still met.) Effected datasets are involved in an upcoming event that has gone through a number of trial runs with approximately the same amount of data, and with people carefully noting transmission times. This increase has had a lot of unfavorable attention. Is anyone familiar with this kind of CONNECT:Direct behavior? Pat O'Keefe ---------------------------------------------------------------------- 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
