The command file is launched, that's all;  there is no "connection" to
break, per se -- all that happens is the "dsmc schedule" daemon gets the
command (from the server's schedule arguments, of course), closes the
session (if prompted scheduling is used) and executes the command.   (The
client already has the command args, in polling-type schedules, so there
would be no session at all, unless/until the command script initiates a dsmc
command.)

The connection between server and client for launching a command file ends
as soon as the data gets passed to the client-scheduler daemon... BEFORE the
command file even runs (essentially).  To see this in action, match the
actlog entries with the dsmsched.log info;  unless you are using
server-prompted scheduling, there is no session/connection between TSM
client & TSM server until/unless the command script contains a
session-creating command (like dsmc).

Most folks will likely have a "dsmc args" (or similar) in the command file,
which creates a session with TSM server to run whatever the args say.  Upon
completion of dsmc command, that completion terminates associated sessions.

Don France
Technical Architect -- Tivoli Certified Consultant
Tivoli Storage Manager, WinNT/2K, AIX/Unix, OS/390
San Jose, Ca
(408) 257-3037
mailto:don_france AT att DOT net

Professional Association of Contract Employees
(P.A.C.E. -- www.pacepros.com)