Unable to delete application group

[jsquizz]

Hi All,

I made some application groups. Turns out that I cannot delete them for some reason. When I do, heres the message that I am getting in the system log-

SM Error: ANS1353E (RC53)   Session rejected: Unknown or incorrect ID entered
, Return Code=53, Reason=0, File=arssmsms.cpp, Line=1141  Srvr->server1<-

I think when I was doing some testing of creating some app groups I picked an old storageset. I don't need these app groups any more and would like to delete them. I tried doing an update via ARSXML which I knew wouldn't work. But why not give it a try?

Any ideas?

[Ed_Arnold]

If you google ANS1353E rc53 there are several hits.

Do any of those help?

Ed

[jsquizz]

Looks like its a TSM related issue and Im having some trouble understanding the link between the objects and my TSM configuration.

[jsquizz]

Figured it out.

Someone has been playing around with TSM in my environment and removed some of the settings under Storage Sets.

Including the name and password ...

Thanks for the guidance though ed.

[Justin Derrick]

Yeah, when you delete an Application Group, IBM CMOD tells TSM to delete the "File Spaces" associated with that Application Group.  If you can't connect to TSM because of a bad/expired password, then the delete is going to fail.

-JD.

[Valentin Schmid]

I just stumble upon the same issue, while deleting an ApplicationGroup.
From the admin client I receive the error: "The server failed while accessing application group data. Contact your system administrator."
(See also: http://www-01.ibm.com/support/docview.wss?uid=swg21272955)

Unfortunatelly the whole TSM node containing the documents of this ApplicationGroup was already deleted some time ago.

Is there a way to delete such orphaned ApplicationGroups without recreating the TSM node?
E.g. by manipulating ARSAG.SID ?

[Justin Derrick]

I'd advise against modifying the database tables without direction from IBM.

Otherwise, you might be able to define the node in TSM again, and have the delete be successful.

Also, you can try changing the node configuration in the Storage Set, but this could affect other AGs that belong to that Set.

-JD.

[jsquizz]

I just stumble upon the same issue, while deleting an ApplicationGroup.
From the admin client I receive the error: "The server failed while accessing application group data. Contact your system administrator."
(See also: http://www-01.ibm.com/support/docview.wss?uid=swg21272955)

Unfortunatelly the whole TSM node containing the documents of this ApplicationGroup was already deleted some time ago.

Is there a way to delete such orphaned ApplicationGroups without recreating the TSM node?
E.g. by manipulating ARSAG.SID ?

that is a very bad idea. There goes your warranty/support from IBM if you have an issue. I've done things like this in the past but only when there was NO other option.

[jsquizz]

So, I am seeing this now in another tier, this time when loading.

Resource testfile.ARD.res will be added as resource >16-10-0<.  Compression Type(OD77) Original Size(7623127) Compressed Size(4430013)
An error occurred.  Contact your system administrator and/or consult the System Log.  File=arsadmp.c, Line=1252
Unable to store the object >16<.  Object size 4430013
arsload: 09/22/17 14:28:15 Loading failed
arsload: Processing failed for file >testfile.ARD<

We've unfortunately had to engage IBM on this one. They shot me over to TSM support.

[Justin Derrick]

I think you posted in the wrong thread. 

[jsquizz]

I think you posted in the wrong thread. 

I believe you are correct. It's been a busy few days in the TSM world, and I'm the TSM admin.

[jsquizz]

Temporary work around. I just needed the app groups deleted because the environment was messy.

Now its messy, just in a different spot. I took the storage set associated with the troublesome application group and copied it - StorageSet.09260217

Then I modified the original StorageSet and pointed it to Cache. Since I didn't have any data loaded that was useful, didn't matter. Once that was done I deleted the application groups successfully and reverted back the old storage set settings.

It was somewhat confusing - mainly because the retention was something like...

Cache for 5 days
move to TSM
Expire @ 30

You'd think that it wouldn't matter if there was no data! Thanks for the pointers.

[Valentin Schmid]

Hello all,

Thanks for all the answers to my question. Especially to jsquizz's workaround.

With this steps I managed to get rid of the orphaned ApplicationGroup:
- Update the "Storage Set" of the orphaned ApplicationGroup (which we eventually want to delete as well, cause we have no use for this anymore)
  -- Add a new "Cache Only"-"Storage Node"
  -- Delete the TSM "Storage Node" pointing to the non-existing TSM node
  -- Update the "Cache Only"-"Storage Node" => Check the "Load Data" flag
  Now it is possible to save the manipulated "Storage Set"
- Delete the orphaned ApplicationGroup (works now without errors)
- Delete the "Storage Set" of the orphaned ApplicationGroup
Done.

Best Regards
Valentin