OnDemand Users Group

Support Forums => CMOD for Multiplatforms => Topic started by: CMOD_CSSAP on March 14, 2012, 03:45:36 AM

Title: ARSLOAD says could not connect to server, which one?
Post by: CMOD_CSSAP on March 14, 2012, 03:45:36 AM
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
Title: Re: ARSLOAD says could not connect to server, which one?
Post by: Justin Derrick on March 14, 2012, 02:09:21 PM
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.
Title: Re: ARSLOAD says could not connect to server, which one?
Post by: Justin Derrick on July 22, 2014, 03:15:55 PM
I recently encountered this issue, in a situation where we were loading data from a 'load server' into a separate 'CMOD server'.

We checked:

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