Author Topic: Validating Cache Storage  (Read 13242 times)

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
Validating Cache Storage
« on: March 09, 2011, 09:34:14 AM »
arsmaint can be run with the following parm:

Quote
-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.
#zOS #ODF

johnnoel

  • Jr. Member
  • **
  • Posts: 35
    • View Profile
Re: Validating Cache Storage
« Reply #1 on: May 23, 2013, 10:34:35 AM »
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

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
Re: Validating Cache Storage
« Reply #2 on: May 27, 2013, 07:40:26 AM »
John - I recommend you open a low-severity PMR with IBM support if no one else answers.

Ed
#zOS #ODF

johnnoel

  • Jr. Member
  • **
  • Posts: 35
    • View Profile
Re: Validating Cache Storage
« Reply #3 on: May 28, 2013, 08:03:17 AM »
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.

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
Re: Validating Cache Storage
« Reply #4 on: May 28, 2013, 06:35:27 PM »
Will keep you posted.

Please do...there's always something new.

Ed
#zOS #ODF

Alessandro Perucchi

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1002
    • View Profile
Re: Validating Cache Storage
« Reply #5 on: June 19, 2013, 04:15:55 AM »
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
Alessandro Perucchi

#Install #Migrations #Conversion #Educate #Repair #Upgrade #Migrate #Enhance #Optimize #AIX #Linux #Multiplatforms #DB2 #Windows #Oracle #TSM #Tivoli #Performance #Audits #Customizing #Availability #HA #DR #JavaApi #ContentNavigator #ICN #WEBi #ODWEK #Services #PDF #AFP #XML

rjchavez

  • Jr. Member
  • **
  • Posts: 67
    • View Profile
Re: Validating Cache Storage
« Reply #6 on: September 16, 2014, 10:13:18 AM »
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!

jeffs42885

  • Guest
Re: Validating Cache Storage
« Reply #7 on: September 17, 2014, 05:10:19 AM »
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.

ewirtz

  • Full Member
  • ***
  • Posts: 134
    • View Profile
Re: Validating Cache Storage
« Reply #8 on: September 18, 2014, 12:18:32 AM »
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

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
Re: Validating Cache Storage
« Reply #9 on: February 08, 2015, 03:52:13 PM »
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
#zOS #ODF

Alessandro Perucchi

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1002
    • View Profile
Re: Validating Cache Storage
« Reply #10 on: March 19, 2015, 08:53:12 AM »

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 :-)
Alessandro Perucchi

#Install #Migrations #Conversion #Educate #Repair #Upgrade #Migrate #Enhance #Optimize #AIX #Linux #Multiplatforms #DB2 #Windows #Oracle #TSM #Tivoli #Performance #Audits #Customizing #Availability #HA #DR #JavaApi #ContentNavigator #ICN #WEBi #ODWEK #Services #PDF #AFP #XML

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
UID = 0 for ARSSOCKD?
« Reply #11 on: March 22, 2015, 03:05:19 PM »
... 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
#zOS #ODF