ARSLOAD says could not connect to server, which one?

[CMOD_CSSAP]

steps.
Search specific files from N drive, if found copy to D drive and run arsload to ARCHIVE instance of CMOD 8.5.3 in W2008, DB2 9.7

Executing Download of PDFs from AS/400
        1 file(s) copied.
Downloading -- copy /Y N:\APP?201202.pdf d:\PDF_Files
N:\APP1201202.PDF
1 file(s) copied.
>Tue Mar 13 20:58:02 2012   d:\IBM\OnDemandServer\bin\Arsload -n -v -f -u xxxxxx -p xxxxxxxx -a APP1 -g GRP1 d:\PDF_Files\APP1201202.pdf
arsload: Processing file >d:\PDF_Files\OAS1201202.pdf<
arsload: Could not connect to server to establish log id

Which server is it trying to connect ? (I believe it is  trying the instance which is ARCHIVE.
>used -I with instance name ARCHIVE, no different result.
>This id has full admin access, logs in to DB2, ADMIN client, Config fine, even starts services.
>
What am I missing here? (the same works in my development server).
Thank you

[Justin Derrick]

Hi.

Just wanted to let you know that I've edited your post to remove the UID & Password that was displayed in clear text.

To answer your question, I'm under the impression that arsload requires the -h parameter.  To load to the local instance of CMOD, I regularly use "-h localhost".  (The name localhost is defined in the TCP/IP specifications, and resolves to 127.0.0.1 -- which is always the system itself, for anyone who's curious.)

Give that a try and let us know if anything has changed.

-JD.

[Justin Derrick]

I recently encountered this issue, in a situation where we were loading data from a 'load server' into a separate 'CMOD server'.

We checked:

• Library Paths (since the arsload trace had trouble finding some of the libraries)
• DNS Issues (checked for properly resolving host names from names specified in the ars.ini file)
• ars.ini & ars.cfg files (checked server names, and configured paths)

In this particular case, it was caused by the load server having been cloned from another region (ie, the loader from the 'dev' environment was cloned to become the loader for the 'test' environment).  The ars.ini file on the loader contained the server name of the development CMOD server, rather than the name of the test CMOD server, as below:


[@SRV@_DEV1]
HOST=ondemand-test1
PROTOCOL=2
PORT=0
SRVR_INSTANCE=archive
SRVR_INSTANCE_OWNER=archive