ARSLOAD Stopped Running in Daemon Mode after ARSSOCKD Terminated Abnormally

[JJeffrey]

We are running CMOD 8.5.0.7 (I know it's unsupported and we upgrade to 9.0 in 3 weeks) and ARSSOCKD terminated unexpectedly for reasons unknown. ARSSOCKD was successfully restarted but it was discovered the next day that ARSLOAD running as a daemon on the server was not loading documents. We've rebooted the server twice to start the ARSLOAD automation but it's not starting, leaving the admins to manually run loads to get documents onto the server. Is there anyway to start the load daemon manually? Should we have made sure the the input filesystem specified in th init.d was empty when we rebooted? Any suggestions on how to solve this since IBM won't look at the PMR without purchasing extended support?

CMOD 8.5.0.7 for MultiPlatforms running on RHEL server. DB2 9.07. TSM 5.5

[bruce.mchendry]

Hi,
Not sure how helpful this is since due to Sun Life requirements my config is different. During the build of all our environments we did a lot of stopping and starting of our daemon during processing. We have changed it again but had set this up as a Windows service and also used a simple batch file. Just for reference we have a standard "C" drive but everything process related is on an "E" drive partition including our custom daemon. Not my call, the server team owns it. Along the trip from Project to Production we had many "educational moments and opportunities for process improvement".

An early one was having the daemon as a windows service so it was easy to stop and start. That was using a functional ID, shared with a couple things, called CMODADMIN. All good until someone changed the password one day and forgot to update the windows service daemon. Another thing we did that worked well was to run a batch file to stop and start like this :
echo
sc start "SunLife CMOD Daemon" CMOD CMODADMIN password -fast
Is that of any help ? Maybe this was too simplifed ? We also had to use a remote SQL database and got into the same trouble once with functional ID's and a changed password. It's things like that can drive yo ucrazy until you figure them out.

Also we recently went from 9 to 9.5 and while it might seem like a huge jump I'm pretty sure technically you could do the same if all the pre-reqs are in place.

[Alessandro Perucchi]

Well normally, ARSLOAD is never started at the beginning to load documents.
It means you MUST have a script to start it automatically at the start of the server, or have in the init.d (or this sh�*t of systemd).

Normally to run it manually, you must run it with the option -d in order to look at which directory to look for files, and it should be also running in "background" waiting for files to be loaded, and also the -c option in order to tell arsload in which directory it must run the indexer.
Now what are exactly the whole parameter list you need, no idea. But it will be at least the argument -h and maybe -u/-p.

I've never used this functionality of arsload (in nearly 17 years and countless number of customer), so cannot help you more than that.
In case, you can look at the documentation of arsload for more help: (http://www.ibm.com/support/knowledgecenter/SSEPCD_8.5.0/com.ibm.ondemand.administeringmp.doc/arsload.htm) and maybe also http://www.ibm.com/support/knowledgecenter/SSEPCD_8.5.0/com.ibm.ondemand.administeringmp.doc/dodlo004.htm.

Good luck

[sisusteve]

To run arsload in daemon mode:

arsload -h <instance> -f -d <data directory> -c <index directory> -t <sleep_time> -u <arsload_user_id> -G <field> -A <field>

This command is defined in a shell script that runs at startup/boot time.  We've been running arsload in daemon mode for over 15 years with multiple CMOD instances (10+) on a single server.

[Alessandro Perucchi]

To run arsload in daemon mode:

arsload -h <instance> -f -d <data directory> -c <index directory> -t <sleep_time> -u <arsload_user_id> -G <field> -A <field>

This command is defined in a shell script that runs at startup/boot time.  We've been running arsload in daemon mode for over 15 years with multiple CMOD instances (10+) on a single server.

The world is wonderful :-) one part is using it for more than 15 years, and another part of the world is not using it at all :-)
I just love it!!!!!!! :-)