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

I have a SQL Server 2000 DTS package that pushes data to the AS400.  The package runs perfectly when run manually.  When the package is run as a scheduled task on the server, it fails and logs the following error message:

[IBM][iSeries Access ODBC Driver]Communication link failure. comm rc=10060 - CWBCO1048 - A time-out occurred trying to connect to the iSeries

The scheduled tasks runs a batch file that contains the following command line:
DTSRun /S "(local)" /N "TransferD3ContactsToNWO" /G "{3077A925-4CE2-4801-8C97-B1F45F3FDF47}" /L "C:\Documents and Settings\AAKLYNCH\My Documents\Logs\DTS_ErrorsD3ContactsToNWO.txt" /W "0" /E

The batch file is run nightly using a Windows scheduled task.

Any ideas why my connection to the iSeries is timing out.  I am using valid AS400 credentials, and as I mentioned, it runs perfectly when done manually.

Note: The transfer of data does take a few minutes, as it is a lot of data.

Thanks for assistance.
LVL 1
NMHGADMAsked:
Who is Participating?
 
nmcdermaidCommented:
You could turn on ODBC logging if the AS400 driver you are using is the AS400 ODBC driver.
Its wierd that its a timeout - that implies that it is connecting OK but can't push the data in. In not throwing a security error which is where I still suspect the problem is.
Some time ago I worked with the client driver (just extracting data). The only way I could do it was use a seperate IBM utility (.EXE file) to extract data to a text file then pick up the text file from DTS. I could not extract directly using the IBM driver.
Perhaps you could try using the IBM text load utiility (comes with the client tools but I don't know its name sorry) to experiment with uploading text files. The utility may give you a clearer error message.
0
 
Atdhe NuhiuCommented:
I suspect it has to do with the permissions of the accounts that run the DTS. They are likely to be different when run maually versus scheduled task.


0
 
NMHGADMAuthor Commented:
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.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
NMHGADMAuthor Commented:
i would still appreciate any assistance from anyone who has any other ideas for things I can check.  thanks.
0
 
nmcdermaidCommented:
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.
0
 
NMHGADMAuthor Commented:
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?
0
 
nmcdermaidCommented:
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'
0
 
NMHGADMAuthor Commented:
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.
0
 
nmcdermaidCommented:
If you are connecting through a DSN, make sure its a system DSN, not a user DSN.
0
 
Youssef HAMDOUNECommented:
Hi i have the same probléme do you finde any solution?
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.