OnDemand User Group
Tips and Tricks => Tips and Tricks => Topic started by: Ed_Arnold on March 09, 2011, 09:34:14 AM
-
arsmaint can be run with the following parm:
-v
Validates cache storage. When you specify this option, the ARSMAINT program inspects all cache storage file systems to make sure that they are correctly linked with the proper file permissions.
I run it in batch on z/OS with the following JCL:
//TMP1 EXEC PGM=IKJEFT01,
// DYNAMNBR=200
//SYSPROC DD DSN=SYS1.SBPXEXEC,DISP=SHR
//*
//SYSTSPRT DD SYSOUT=*
//*
//SYSTSIN DD *
oshell /usr/lpp/ars/V8R4M0/bin/arsmaint -v -I ARCHIVE
//*
Note: on z/OS at least - the output does not go in the job. Rather the output will show up in the ARSSOCKD started task.
If there is no problem, there is no output.
If there is, you can expect to see a message like this in the JESMSGLG:
ARS0198E ARSMAINT INVALID OWNERSHIP AND/OR PERMISSIONS ON CACHE FILE
/DIRECTORY >/ARS2< SRVR->MAGENTA.ZOS.FOO.COM 9.29.129.129<-
Warning - can be rather I/O intensive, try it on a test system first or run it off-shift.
-
Ed,
I am on Windows and scheduled the ARSMAINT to run, but after a couple Message 164s, I get a message 198
What ID should be the owner of these files? And what permissions should be set?
124 Filesystem Stats Name(m:\arscache1\CMODPROD) Data(84%) Inodes(-2147483648%) Srvr->usgobtcmod40.somecompany.com <-
32 Logoff
198 Invalid ownership and/or permissions on cache file/directory >m:\arscache1\CMODPROD\17377\XEA\DOC\1827FAAO< Srvr->usgobtcmod40.somecompany.com x.x.x.x<-
164 Application Group Segment Maintenance: Name(DOC1010YR) Agid(5206) SegName(IAA1) Action(2) Time(37.109)
164 Application Group Segment Maintenance: Name(DOC101YR) Agid(5248) SegName(JAA1) Action(2) Time(0.984)
164 Application Group Segment Maintenance: Name(DOC102YR) Agid(5342) SegName(LAA1) Action(2) Time(10.703)
164 Application Group Segment Maintenance: Name(DOC107YR) Agid(5403) SegName(OAA1) Action(2) Time(14.875)
164 Application Group Segment Maintenance: Name(DOC1030D) Agid(5393) SegName(MAA1) Action(2) Time(0.078)
164 Application Group Segment Maintenance: Name(DOC1090D) Agid(5494) SegName(PAA1) Action(2) Time(0.172)
164 Application Group Segment Maintenance: Name(DOC10GDO) Agid(5853) SegName(ZBA1) Action(2) Time(0.734)
164 Application Group Segment Maintenance: Name(DOC10GDA) Agid(5839) SegName(TBA1) Action(2) Time(0.016)
164 Application Group Segment Maintenance: Name(DOC10GD) Agid(5833) SegName(RBA1) Action(2) Time(0.031)
164 Application Group Segment Maintenance: Name(DOC10CMB) Agid(5637) SegName(CBA1) Action(2) Time(0.188)
164 Application Group Segment Maintenance: Name(DOC10CMA) Agid(5635) SegName(BBA1) Action(2) Time(0.032)
164 Application Group Segment Maintenance: Name(DOC10AWO) Agid(5575) SegName(TAA1) Action(2) Time(0.062)
164 Application Group Segment Maintenance: Name(DOC10ACO) Agid(5499) SegName(QAA1) Action(2) Time(0.094)
164 Application Group Segment Maintenance: Name(DOC10GZA) Agid(6022) SegName(DCA1) Action(2) Time(0.516)
164 Application Group Segment Maintenance: Name(DOC10GWA1YR) Agid(6020) SegName(CCA1) Action(2) Time(0.047)
164 Application Group Segment Maintenance: Name(DOC10GW) Agid(6011) SegName(ACA1) Action(2) Time(0.063)
164 Application Group Segment Maintenance: Name(DOC10SPO) Agid(6278) SegName(VCA1) Action(2) Time(29.938)
164 Application Group Segment Maintenance: Name(DOC10GZB) Agid(6024) SegName(ECA1) Action(2) Time(0.140)
164 Application Group Segment Maintenance: Name(DOC10STO) Agid(6282) SegName(XCA1) Action(2) Time(0.609)
164 Application Group Segment Maintenance: Name(DOC18) Agid(6678) SegName(IDA1) Action(2) Time(39.468)
164 Application Group Segment Maintenance: Name(DOC10ZZB) Agid(6594) SegName(ZCA3) Action(2) Time(0.891)
164 Application Group Segment Maintenance: Name(DOC35A) Agid(6805) SegName(YDA1) Action(2) Time(20.906)
164 Application Group Segment Maintenance: Name(DOC18GDA) Agid(6791) SegName(TDA1) Action(2) Time(0.078)
164 Application Group Segment Maintenance: Name(NODX10AA) Agid(6976) SegName(FEA1) Action(2) Time(1.157)
164 Application Group Segment Maintenance: Name(NODX10AA2YR) Agid(7222) SegName(KEA1) Action(2) Time(0.625)
164 Application Group Segment Maintenance: Name(NODX10AA1YR) Agid(7180) SegName(IEA1) Action(2) Time(0.157)
164 Application Group Segment Maintenance: Name(NODX10AA7YR) Agid(7268) SegName(NEA1) Action(2) Time(1.406)
164 Application Group Segment Maintenance: Name(NODX10AA60D) Agid(7260) SegName(MEA1) Action(2) Time(0.062)
164 Application Group Segment Maintenance: Name(NODX10AA30D) Agid(7246) SegName(LEA1) Action(2) Time(0.125)
164 Application Group Segment Maintenance: Name(PDF31A) Agid(7377) SegName(EFA1) Action(2) Time(27.719)
164 Application Group Segment Maintenance: Name(NODX18AA) Agid(7341) SegName(QEA1) Action(2) Time(0.110)
164 Application Group Segment Maintenance: Name(NODX10AA90D) Agid(7331) SegName(OEA1) Action(2) Time(0.031)
164 Application Group Segment Maintenance: Name(PDF33) Agid(7399) SegName(HFA2) Action(2) Time(29.391)
164 Application Group Segment Maintenance: Name(PDF37A) Agid(7411) SegName(JFA17) Action(2) Time(10.453)
164 Application Group Segment Maintenance: Name(System Load) Agid(7562) SegName(SA2) Action(2) Time(8.625)
164 Application Group Segment Maintenance: Name(System Log) Agid(7603) SegName(SL7) Action(2) Time(25.265)
164 Application Group Segment Maintenance: Name(PDF14D) Agid(7652) SegName(UFA6) Action(2) Time(25.046)
30 Login: usgobtcmod40.somecompany.com x.x.x.x
Thanks,
John
-
John - I recommend you open a low-severity PMR with IBM support if no one else answers.
Ed
-
Thanks Ed.
I noticed that on our Production server, the permissions and ownership of the arscache files and folders were not full control and ownerd by the ID used to install OnDemand (like it is on the DEV and INT servers.) The ownership got switched I think when we moved the data from the local server HDD to SAN and the Distributed Systems ID was used for that.
I have asked our Distributed Systems team to change the Ownership of that one file to the OnDemand Schema ID that the Sceduler Service runs under. I will wait to see the results tonight. If it still fails, then I will ask that they also give the ID Full COntrol of the file (right now it has Modify.)
Will keep you posted.
-
Will keep you posted.
Please do...there's always something new.
Ed
-
Here is my .2 cents with Windows and CMOD.
I have a customer which use CMOD with Windows (Well I had a customer because we migrated from Windows to Linux... not plug'n'play migration, but quite interesting :-D) and he had quite often such errors.
And by correcting the permissions, it solved all his problems.
But for unknown reasons these messages where popping from time to time. And we never found the root cause. But by changing the permission it helped.
Sincerely yours,
Alessandro
-
Sorry for bringing this topic back to life but, I have a very similar situation running CMOD under zOS using USS. I've checked the permission bits and all seem correct.
The user assigned to the ARSSOCKD task has superuser (uid=0) authority (and should have full authority to the files/directories) but I'm still getting the following error when trying to validate the cache:
Invalid ownership and/or permissions on cache file/directory >/fpl/ars1/ARSDBASE/22289/SL/DOC/79FAA< Srvr->erpr.fpl.com 155.109.247.41 non-SSL<-
Any help would be appreciated!
-
Will keep you posted.
Please do...there's always something new.
Ed
I was once part of an effort to migrate from Cache storage to TSM and I've seen a similar situation where the actual cache directories had their permissions changed and it caused all kinds of headaches, file failures, files not being able to retrieved, etc.
-
Hi to all,
I have forgotten the details. But as far as I remember the permission bits are used for the technical process itself. Thex were used to store informations. So it's not anough that the user has the right to see the files.
regards
Egon
-
Sorry for bringing this topic back to life but, I have a very similar situation running CMOD under zOS using USS. I've checked the permission bits and all seem correct.
The user assigned to the ARSSOCKD task has superuser (uid=0) authority (and should have full authority to the files/directories) but I'm still getting the following error when trying to validate the cache:
A little late in replying but I just noticed this.
You should not be running ARSSOCKD under a UID=0 userid.
Ed
-
You should not be running ARSSOCKD under a UID=0 userid.
I'm 100% with you on that one, but if you read the documentation, every example they are using "root" (or UID=0) as installation of a new instance of CMOD... maybe that would be great to modify the documentation and NOT to have such high security risk example...
what do you think? Maybe that should be something for the enhancement request :-)
-
... if you read the documentation, every example they are using "root" (or UID=0) as installation of a new instance of CMOD... maybe that would be great to modify the documentation and NOT to have such high security risk example...
what do you think? Maybe that should be something for the enhancement request :-)
(Insert emoticon of hand hitting forehead.)
Another item for my to-do list.
Ed