ARSLOAD fine if indexing and archiving correctly. Process hangs if fails

[jpdevin]

 We experienced problems on our backleveled CMOD (AIX, DB2, TSM) which we are planning to upgrade soon. This ultimately was due to the TSM database filling up and saturating at 100% utilization. As part of the resolution process, we recycled the production server.
 Since that time, as long as ARSLOAD is successful it works normally. However, for the small percentage of files that need to fail, it puts the standard 88 message in the syslog, then the process hangs and must be manually killed.
 Only then does it react as it used to, appending the back input file name as .FAILED and continuing onto the next file to load. No obvious syslog error messages.
 Not sure if related, but we have another process which is also hanging. If we run ARSMAINT w/o specifying a Application Group, it hangs. We had a scheduled process to reduce it to the standard 80% once nightly. If we run ARSMAINT vs an application group or groups, it works for the most part. Although we seen to have lost link to DB2 occasionally and had to recycle that connection.
 It seems that may be due to the dreaded "broken links in cache" issue, which doesn't seem to have a well documented solution.

[Alessandro Perucchi]

Hello jpdevin,

Sorry for being so late in the answer...

Well it is quite difficult to say anything here... what kind of OS, Version of each component are you using?
Did you do an upgrade in the meantime?

Did you open a PMR for it?

Concerning the cache links, except for some strange cleanup, I had never seen really problems with it... and when you have it, then you need to recreate the link.
Well if the cache file is still there of course :-D

Can you give us some more information about the cache and link problem?

Happy new year and sincerely yours,
Alessandro

[jpdevin]

 Upgrade to latest and greatest still in progress. Current/old environment as mentioned in the orginal post: CMOD (V8.3) on AIX.
PMR avenue not available due to release levels. IBM refused to assist. We did diagnose to the point that it was apparent the Level 1/Level 2 support on the phone did not know what to do.
 We've been doing workarounds since September when TSM database saturated to 100% unknowingly for 3 system processes not fully working.
 1) Clearing Cache via ARSMAINT: we have a scheduled process that was this: /usr/lpp/ars/bin/arsmaint -cms -x 0 -n 0
with the system parameter set to 80% I believe.
 Started getting syslog error message 106.
Unlink failed for file arscache/cache1/retr/APE/DOC/nnnnFAAA

Process hangs and must be killed manually.

 However, doing arsmaint manually vs specific groups works for the most part
/usr/lpp/ars/bin/arsmaint -cms -g abcde -x 0 -n 0
 Summary: cache still there, working somewhat, but compromised

 2) ARSLOAD - if it needs to fail only. Do get an 88 msg in syslog, but must manually kill the process in AIX. Only then the bad file gets renamed to xxx.yyy.zzz.FAILED
 3) We intermittently lose connectivity to DB2 database.