I've seen it now and again, on Solaris clients. In the dsmerror.log file I see... 07/07/05 08:31:54 Trying port number 1502 07/07/05 08:31:54 Trying port number 1503 07/07/05 08:31:54 Trying port number 1504 07/07/05 08:31:54 Trying port number 1505 07/07/05 08:31:54 Trying port number 1506 07/07/05 08:31:54 Trying port number 1507 07/07/05 08:31:54 Trying port number 1508 07/07/05 08:31:54 Trying port number 1509 07/07/05 08:31:54 Trying port number 1510 07/07/05 08:31:54 Trying port number 1511 07/07/05 08:31:54 Trying port number 1512 07/07/05 08:31:54 Trying port number 1513 07/07/05 08:31:54 Trying port number 1514 07/07/05 08:31:54 Trying port number 1515 07/07/05 08:31:54 Trying port number 1516 07/07/05 08:31:54 Trying port number 1517 07/07/05 08:31:54 Trying port number 1518 07/07/05 08:31:54 Trying port number 1519 07/07/05 08:31:54 Trying port number 1520 07/07/05 08:31:54 Trying port number 1521 07/07/05 08:31:54 Trying port number 1522 07/07/05 08:31:54 Trying port number 1523 07/07/05 08:31:54 Trying port number 1524 07/07/05 08:31:54 Trying port number 1525 07/07/05 08:31:54 Trying port number 1526 07/07/05 08:31:54 Trying port number 1527 07/07/05 08:31:54 Trying port number 1528 07/07/05 08:31:54 Trying port number 1529 07/07/05 08:31:54 Obtained new port number on which to listen.
personally I think the client scheduler walks on itself... the client scheduler seems to find another port and relays that back to the tsm server, thus the tsm server can still contact the client with everything else I have to do, I've not worried about this since it hasn't resulted in any failed processing in my environment Dwight E. Cook Systems Management Integration Professional, Advanced Integrated Storage Management TSM Administration (918) 835-3106 (local Tulsa OK) (877) 625-4186 T/L 349-4361
