OnDemand User Group
Support Forums => MP Server => Topic started by: mroutlander on April 26, 2018, 09:25:08 AM
-
Greeting fellow ODUsers,
I am facing a strange and baffling error for the past three days. I set out to process 111 odd reports using the arsload daemon. While 107 of those got processed successfully, I am facing the following error for the remaining 4:
The application group >< does not exist or user >ADMIN< does not have permission to access the application group
That "><" is essentially weird because the appgroup in question does exist and ADMIN does have administrative permissions on it. The report format is standard across the 111 reports - AG.APP.IGN.IGN.ARD
OS: AIX 7.1.0.0
CMOD: CMOD for Multiplatforms 9.5.0.9
What could be going wrong? Any help would be really appreciated.
Thanks and Warm Regards,
AP
-
Do you have an input exit which might be getting in the way?
Ed
-
Thanks for responding, Ed. Yes, there is an input exit but that primarily deals with user validation and the user in my case is same across all reports.
-
Can you show us your load command? Obviously, obscure any private information (hostnames, userids, passwords) when you paste them into the forums.
-JD.
-
Thanks for responding, JD. Here is the command (invoked via a script and supposed to run as a daemon):
/ondemand/bin/arsload -I ARCHIVE -fv -t 3600 -B AG.APP.IGN.IGN.EXT -c /arstmp -d /arslocation/filestobeloaded > "/arslocation/logs/arsload.log$(date +%Y%m%d%H%M%S).txt" 2>&1
-
That is *really* weird.
What happens when you run the command against the files, without the -d option, but specifying the file name?
-JD.
-
That doesn't run either and fails with the same error.
-
Weird. Are their any spaces or unicode characters in the file name?
Does it load if you specify the Application Group and Application names on the command line with -g and -a?
-JD.
-
It gets interesting here. There are no spaces/unicode characters in the file name and when processed with the -g and -a option, the file gets processed as it should be - ARS4317I Processing successful for file >filename<
Why this hypocrisy by arsload? :-\
Regards,
AP
-
Sounds like a bug. Consider running again with the trace function, and submitting that to IBM in a PMR.
And I think it's been confirmed -- here's an APAR that was fixed in IBM CMOD v9.5.0.10:
PI89396 - The arsload -B command fails when the Application Group and
Application are in different locations in the file name
You can get IBM CMOD download fixpacks here: https://cmod.wiki/index.php?title=Main_Page#IBM_CMOD_Fixpacks_.26_Security_Bulletins
-JD.
-
Thanks a lot, JD! I was thinking on the same lines. As suggested, will raise a PMR to start with, and if IBM insists on a fix-pack upgrade (which I am guessing they are going to), will proceed with that.
Regards,
AP
-
I'd actually start with the FixPack. Like I said, it seems like they've already addressed this bug.
-JD.
-
I have received this error many times on Linux running the arsload daemon. I have always seen an issue with the input file name. The worst one had a space at the beginning file name, once imbedded on the file name. Also if the file name does not have the exact amount of nodes in the files name as your daemon, it will get this error. The space in the file name will do that - cause CMOD to stop examining the file name after the first space. Just to double-check that before going fix-pack.
-
Thanks ssorich. While I've checked the filenames (of the failing files) for any such anomalies, I'll revisit and check again.
And thanks JD, for the fix pack download link. Once I am done reverifying the filenames, I'll probably install 9.5.0.10. Hopefully that'll fix the issue :)
-
If you check that link, 9.5.0.11 was just released along with a security bulletin for the Global Security Kit, which is used by IBM CMOD to provide cryptographic functions. https://www-01.ibm.com/support/docview.wss?uid=swg22014722
-JD.
-
Thanks for the suggestion, JD. We were about to sign-off the UAT installation when I saw this error. If we are to install 9.5.0.11, probably another couple of weeks would go to DEV and UAT testing. Then there is this issue of ICN setup compatibility. Will look into it though. I am totally pro-upgrade but if we find a way out otherwise, I shall share the same with fellow ODUsers.
Regards,
AP
-
Apologies for the delayed reply. The activity was back-burnered for a while and just got back on track. We are going to upgrade to the latest fix pack (9.5.0.11) as suggested by JD (thanks :) ) . I will let the group know how that pans out.
Warm regards,
AP
-
Greetings Fellow ODUsers,
Apologies for such a delayed response. The good news, though, is that we were able to solve this issue by upgrading to 9.5.0.11. We had to raise a PMR because the arsload version was not upgraded in the initial 9.5.0.11 installation (that ideally should have). IBM suggested to do a re-installation of this fix pack after killing any running arsload processes/daemons. We did so and voila! all the files are getting processed successfully now by the arsload daemons. Thanks for your inputs, everybody!
Warm regards,
Abhinav