Communication link failure. A time-out occurred trying to connect to the iSeries Step

thanks andycrofts.  yes, i am aware of that.  that's why we use a batch file rather than a scheduled job in SQL.  we can control the account that the batch file runs under.  the account we use has full rights to run packages.  i have many other packages that use the same model and all run fine.  what's different about this package is that it connects to the AS400 using the IBM iSeries client, and that is where the failure is occuring.  for some reason, the iSeries connection is timing out.

i would still appreciate any assistance from anyone who has any other ideas for things I can check.  thanks.

Its generally not a good idea to refer to a user specific folder (i.e. My Documents) when you are doing this cross user type of thing.

I second andycrofts suggestion that its a user thing. To veify, why don't you temporaily change the windows scheduler to be your login and see if it works.

ALternatively, log in as the windows scheduler account and run it nd see, for example, if you get any message boxes popping up.

did the following:
- signed on to the server as the account that runs the scheduled task.  ran the dts package.  it completed with no failures.
- i am removing command that writes to the log file in the My Documents folder.  i will see if the package runs on next scheduled instance.

until I get that info, i believe the task and dts package are running fine from an account stand point.  it looks like the connection to the iSeries (AS400) is timing out and failing the task.  connecting to the iSeries requires a username and password that are different than the account that runs the task, as it is used to access the AS400 to write the data to the AS400 library.  so i think the culprit is in there some where.  it's a big file, and it takes a while to send, so maybe there's some timeout setting in SQL I can change?

But the SQL timeout setting should apply no matter what the user is.

Is there a monitoring tool for AS400 that you can use to see if it is connecting?

Also another comment (which is unlikely to have anything to do with your current issue): I would be wary of using the /G switch - it means that you aren't using the latest version of your package. I would remove it if I were you. It is basically a version stamp and it says 'always use this version'

thanks for the tip on the version stamp tip.  i have no tool for monitoring the connection to the as400, but i know that when i run the package manually, i have no connection issues.  it's only when it runs on a schedule.

removing the writing of the log file to my documents didn't help resolve this.  i just checked last night's run.

i have no idea what else to check.