"ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> wrote on 12/18/2003 06:48:14 AM:
> >... ANR2579E Schedule SAP_ONLINE in domain TDP_SERVERS for node > SAPQA-TDP failed (return code 1). > > John - This probably reflects a POSTSchedule or PRESchedule command > failure, where > return code 1 typically accompanies "Command not found". > Check that out. The schedule runs a shell script (action=command) and the shell script does its own error checking and exits with a return code of 1 if there is a problem, that is where that return code is coming from. > > If your Solaris sessions remain problematic, and neither the client > nor server end > reflects an action by its end in causing session severance, then it > would seem that > something in between is causing it. Check your Solaris syslog for > error indications, > which may have affected things other than the TSM session, too. > We've seen a good > number of Solaris-related postings where session problems were > caused by ethernet > autonegotiation being in effect. Check the network configuration of > that Sun box > as compared with other Suns not exhibiting the problem, and compare > commonality of > subnet/switch connection. You could also conduct beefy, manual TSM > sessions, such > as large Backups, to try to make the problem occur under observation. > > Richard Sims, BU The syslog is pretty much useless, nothing but sendmail entries. The backup runs fine if I run it manually, it also works if I schedule it to run on its own with no other backups running at the same time. The configuration of this box is identical to the other 2 Suns, in the same switch also. I thought network problems, but I have run the backup manually at least 20 times without a single problem. I have it scheduled on its own for now as a work around. I think the problem is that the api/DB2 combination is not waiting properly when the session goes to media wait for longer than 5 minutes or so.
