System log messages.

[pankaj.puranik]

Hi

I loaded a file in an app group that loads data directly to SAN.
Following are the messages that are logged in System Log.
Why do I see multiple message number 82 here each with a different ObjName?

I want to capture the storage object name but with multiple message 82, how do I know which one is correct?

30   Login: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx non-SSL (AIX) (ARSDOC) (8.5.0.5) 32   Logoff 87   Application Group Load: Name(CFSCearTSM) LoadId(5222-5-0-1FAA-14245-14245) File(/cna1/cfsc/3146016/ingestion_ear/00015255.aa) InputSize(85795) OutputSize(17184) Rows(2) Time(8.7950) Appl(CFSCearTSM) 32   Logoff 86   Application Group Load Database: Name(CFSCearTSM) Agid(5222) Rows(2) 82   Application Group Object Store: Name(CFSCearTSM) Agid(5222) NodeName(sannode) Nid(5) Server(-LOCAL-) ObjName(1FAA1) Time(0.036) 329   Load Monitor Table Add: Agid(5222) LoadId(5222-5-0-1FAA-14245-14245) 82   Application Group Object Store: Name(CFSCearTSM) Agid(5222) NodeName(sannode) Nid(5) Server(-LOCAL-) ObjName(2) Time(0.204) 82   Application Group Object Store: Name(CFSCearTSM) Agid(5222) NodeName(sannode) Nid(5) Server(-LOCAL-) ObjName(1FAAA) Time(0.054) 30   Login: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx non-SSL (AIX) (ARSLOAD) (8.5.0.5)

[Justin Derrick]

There are multiple objects when you do a load. 

1FAAA1 is index information.  "2" is a resource object.  "1FAAA" is your data.

-JD.

[rick]

JD, As per my understanding index is stored on library server. Is it stored in object server too?

Another question which turn up is, I have seen object names as 1FAA1, 1FAA2, 1FAA3 ... so on... So are all these too indexes?

[pankaj.puranik]

That would mean I will have to somehow get the ObjName for the data alone when I have to do the deletion from SAN as my index and resources would be in cache.

[Justin Derrick]

Fred:  Yup.  Index information is ALSO kept with the objects themselves as a backup, they aren't accessed on a regular basis.

Pankaj: Use arsmaint to expire data from the cache/TSM, arsadmin unload to unload a file, or arsdoc delete to delete a single record.  I'm not sure what you're trying to acheive, but please try to use the built-in utilities to do your data management wherever possible.

-JD.

[pankaj.puranik]

I would also want to stick to what you suggested JD but here's how our setup is.
We have a 0 day TSM node meaning if I run the TSM expiration, it would delete everything that is loaded till date. Sounds funny.. but this is how it is.

So in my case I have to specifically delete objects from CMOD.
I found some undocumented commands that would do this.
Need to try them on DEV.

I just want someone to confirm if the object name 1FAAA, 1FAA1, 2 would be unique across all the loads so that if I delete them, it should not affect any other loads in the system.

Could someone confirm?

Thanks
Pankaj.

[pankaj.puranik]

Here is what I see in TSM.

select object_id,FILESPACE_NAME from archives where node_name='SANNODE' and LL_NAME='3FAAA'

           OBJECT_ID     FILESPACE_NAME
--------------------     ------------------
               50259     /CMODDBP/SBA
               48139     /CMODDBP/TBA
               48313     /CMODDBP/UBA

I want to delete 48139. Here TBA is the AG identifier.
I just want to know if deleting 48139 would affect any other loads aprt from the one that I want deleted from TSM?

[Justin Derrick]

Again, I'll advise you to NOT perform your deletions at the TSM/Cache level -- it's too easy to make a mistake, and won't be supported should you run into trouble...

Having said that, to answer your two questions:

Yes, 1FAAA and 1FAA1 should be unique inside an Application Group / TSM Filespace.

I'm not sure how object ID is used inside the TSM database (because that field and it's relations to other tables inside TSM aren't fully documented).  You can't be sure that deleting a row in the database table won't cause integrity issues elsewhere.

One last time:  Please try to find a supported way to meet your customer requirements.

[pankaj.puranik]

I will raise a PMR with IBM and see if they have a safer solution to our problem.
Will post back.

[pankaj.puranik]

Found this nice post on this forum on a similr topic.

http://www.odusergroup.org/forums/index.php?topic=610.msg3401#msg3401

[Alessandro Perucchi]

Hello Pankaj,

Why do you want to play with the files in TSM?
If you delete the wrong file, you end up having a not usable CMOD...

Personally I don't see any use case that validated a need to touch TSM to delete objects.
Well there is only one... You have no index index in the library server, because they are expired or deleted via arsdoc delete. And since you cannot reach anymore the object in TSM, then you want to delete them.

I see no other use cases. And of course, that way of doing is not supported...

Would you mind to explain what is your goal by fiddling like that inside CMOD?

Sincerely yours,
Alessandro

[pankaj.puranik]

Thanks Alessandro.

Here's the scenario.

1. We load data directly into archive (no caching).

2. The node on TSM that is used for storing the data/resources is a zero day node (zero day retention).

3. I have to run arsadmin unload on certain loads as they have bad data. Running arsadmin unload would remove the data on cache if any and remove the index from database. That would leave orphan documents in archive.

4. Since we have a zero day node, we cannot run the inventory expiration on TSM as that would delete all the documents that are loaded till date.

5. This means that I will have to run arsadmin unload on CMOD and then use 'delete object' on TSM for those orphaned objects.

This whole issue is because of the zero day node. Unfortunately, our client decided to go for the zero day node so that they can remove data whenever they want and reclaim the space in SAN.

Given this scenarion could you answer the following :

1. What options I have now to delete the objects from TSM (supported/unsupported)

2. Give the requirement above, could there have been a better solution than using a zero day node.

THis setup has been there before I joined this project, so can't really change it now.

Thanks
Panakj.