ARSLOAD daemon vs manual

[rmazurki]

Hi,

I was trying to search this forum for that topic but I didn't succeeded.
Our system is CMOD 9.5, Redhat Linux 6.10, DB2 + TSM.
On our site currently we are using load deamons - ARSLOAD -d for some directories.

Currently we are designing new process for loading another data.
I belive we can use manual ARSLOAD download in our process instead of load daemons.
But what are the pros an cons of this kind of approach?

It looks like that load daemons are more popular but is this better solution?

Regards
Rafal Mazurkiewicz

[jsquizz]

I've seen both. We used manual calls of arsload when the file name wasn't compliant, or it was something weird like that.

With all the CMOD customers I've seen, we have used daemons, usually multiple. And there has been zero issues at all. I guess it depends on what you're loading and your volumes.

[Justin Derrick]

Running arsload as a daemon is simple and reliable.  If you need to 'wrap' arsload with your own custom process, I recommend having the files arrive in a staging area, and once your custom process is complete, moving them into a directory that arsload is monitoring in daemon mode so it can be loaded into CMOD.

If you want to monitor the process for success of failure, consider adding some code to the logging exit, arslog.

-JD.

[rmazurki]

ok. Thanks for the replies 

[Alessandro Perucchi]

To be honest, I've never used the daemon mode. I've tried it a long time ago (something like 10-15 years ago), and didn't like it.
I prefer to have the complete control of what arsload does. And after going to IBM, all my customers that were not on z/OS was doing the same as me. The z/OS people loved the daemon mode.

I think it is a question of taste and color. If you like that mode, then go for it.
If you need more control, and you need to do lots of pre-post processing, then the manual mode might be better for you.

In all case, the advice of @Justin is good concerning adding some code in the logging exit (arslog), but I would just advice to make it as simple as possible, and not put too much logic behind, the shorter and fastest, the better.
Today with CMOD the call to arslog is done in an async mode, that way it doesn't slow down CMOD. But nevertheless try to get the info you need with arslog, and then another script/program will get the output of your custom code to do something more beefy!

Alessandro

[SacramentoUser]

Hey all,

I support CMOD 9.5 on a RHL platform.  We run both sort of these processes.  Our enterprise scheduler executes the ARSLOAD commands when a process that deposits data into a specific directory has completed.  We have very simple scripts to do this.  It works well for us.   We also use the scheduler's file watcher capability.  When a file appears in a directory, the scheduler executes the ARSLOAD commands via a script.

Hope the info helps.

[Justin Derrick]

Yup, if your organization has some sort of enterprise-scheduling or orchestration tool, it's great to integrate your loading into that.  It takes away a lot of the 'babysitting' of arsload -- looking for files that should have arrived, but have not, and finding failed loads -- the scheduler/orchestrator knows about the failures right after they happen, and can alert the people that hopefully aren't you. 

-JD.