CMOD client 8_5_0_6 accepts incorrect Applgroup definitions - how to clean up

[JGODFROID]

Hello.
We have migrated from CMOD z/OS 8.4.1 to CMOD z/OS 8.5.
We have installed CMOD client 8_5_0_6 client and admin on some Windows PC, as this looked to be the only version tolerating servers in 8.4.1 and 8.5.
The client part runs well, the 'admin' part much less... 
One of our authorized users has defined two application groups in which some critical information was missing (storage set...);
CMOD client 8_5_0_6 should have refused these definitions... it did not.
When we try to 'update' and fill up missing information, the client does send any message but updates are not done (more exactly some are done others are not)
And when we try to suppress this 'garbage' we got a message sounding like : 'unable to delete application group 'ODRNRPP' - A return code of 'Not Exist' was returned from the server'  (ODRNRPP is one of the faulty application group).
We have now installed the latest CMOD client we could find (9.5.0.1); it seems to check entered info much more seriously... but is not able to clean up faulty application group previously created with CMOD client 8_5_0_6.

Any idea about how we can perform this cleanup ?
Fortunately, our authorized users always test creation of new objects in a Ondemand test environment, but now they no longer trust CMOD clients... 
And the migration from CMOD 8.5 to CMOD 9.5 that was planned for the next weeks, makes them scared.

Any suggestion or help will be appreciated.

Tks upfront.

Jean
 

[Ed_Arnold]

You might try to see if ARSXML can do this for you.

If you look at the .../bin/xml/samples directory you'll see some XML samples.

Try the following JCL....I probably have way too many STEPLIBs and other libraries, you might be able to get by with just barebones:

//STEP1    EXEC PGM=BPXBATCH,REGION=0M                         
//*                                                             
//STEPLIB  DD DISP=SHR,DSN=ARS.ARSV850.SARSLOAD                 
//         DD DISP=SHR,DSN=DSN.DB2VA10.SDSNEXIT                 
//         DD DISP=SHR,DSN=DSN.DB2VA10.SDSNLOAD                 
//SYSPRINT DD SYSOUT=*                                         
//SYSOUT   DD SYSOUT=*                                         
//STDERR   DD SYSOUT=*                                         
//STDOUT   DD SYSOUT=*                                         
//STDPARM DD *                                                 
PGM /usr/lpp/ars/V8R5M0/bin/arsxml                             
delete                                                         
-h ARCH850 -u odadmin -p donnybrook -v                             
-i /usr/lpp/ars/V8R5M0/bin/xml/samples/deletegroups.ebcdic.xml 
//STDENV DD *                                                   
CLASSPATH=/usr/lpp/ars/V8R5M0/bin/xml/ODAdmin.jar:             
          /usr/lpp/java/J8.0_64/lib/core.jar                   
LIBPATH=/usr/lpp/ixm1a/IBM/xml4c-5_7/lib/:$LIBPATH             
PATH=/usr/lpp/java/J8.0_64/bin:/usr/lpp/ars/V8R5M0/bin:$PATH   
/*                                                             

Of course, one would edit deletegroups.ebcdic.xml to match the groups you want to delete.


Not sure, but you may want or need to delete the applications first.

In that case, use this as a sample:

applicationAdd.ebcdic.xml

All you need I think is the application name="Daily sales invoices" part of the XML.

Ed

[JGODFROID]

Thanks for your suggestion, Ed.
Using arsxml looked to be a nice idea and I tried it.
Unfortunately here is what I get :

Attempting login for userid 'odadmin' on server 'SYST1' ...
Deleting group, ODRNRPP                                     
A group object named 'ODRNRPP' does not exist.             
Delete of group, ODRNRPP failed.                           

Despite the fact that we still can see this application when using the CMOD client;
by the way, our DB2 admin told me that there is a row for ODRNRPP in 'AGID' table.
but we don't dare to simply delete this row...
 

Might it be that arsxml is seaching only in 'groups' and not in 'Application Groups' ?
As far as I could see, there is no specific xml sample to delete 'application groups'.

Jean

 

[Ed_Arnold]

Hi Jean -

>  there is no specific xml sample to delete 'application groups'.

This is exactly how I delete application groups:

//STDPARM DD *                                                 
PGM /usr/lpp/ars/V8R5M0/bin/arsxml                             
delete                                                         
-h ARCH850 -u odadmin -p guessing -v                           
-i /usr/lpp/ars/V8R5M0/bin/xml/samples/applgroupAdd.ebcdic.xml

(same input file as for an ADD, just do a DELETE)
...

If I was really good, we'd use UPDATE to make the changes you want.   

How I'd do that is first EXPORT out a good record, change the values as desired, and then use that record for an UPDATE.

Ed

[Ed_Arnold]

One last tip - before running any arsxml input live do a VALIDATE on it:

//STDPARM DD *                                                   
PGM /usr/lpp/ars/V8R5M0/bin/arsxml                               
validate                                                         
-h ARCH850 -u odv733 -p noyoudont -v                               
-i /usr/lpp/ars/V8R5M0/bin/xml/samples/applgroupAdd.ebcdic.xml

No messages and a return code of 0 means that the input passed basic checking....   i.e. no news is good news.

I wish there was a message like "ARS9999I - input passed validation" but there isn't.   

Ed

[Ed_Arnold]

> Any idea about how we can perform this cleanup ?

Just thinking about this a little more.

Try doing an export of the server definitions to a local database, and then reimporting that back in.

Ref (a):  http://www-01.ibm.com/support/docview.wss?uid=swg21392609

Ref (b):  http://www-01.ibm.com/support/docview.wss?uid=swg21191234

I've found that sometimes the act of exporting and importing will clean up some forms of bad entries.

Ed

[Alessandro Perucchi]

The only moment that I've seen such behavior was when some information in the database (ars% tables) where "corrupted", and because of that sometimes the admin client was totally lost. By looking in the tables itself and retrying to figure out the missing pieces, cleaning up the orphans pieces and/or changing some strange values, then the correct behavior was restored.

Now what is your problem, I have absolutely no idea, but maybe you've lost some links between the cmod objects, and therefore causing such problems. And arsxml / local server import-export won't help you at all. (I've already went that road many times unfortunately) And the only way is looking at the database values itself... at least that was my experience in the MP world of CMOD. That doesn't happen often... but it can happen.

Kind regards,
Alessandro

[Greg Ira]

Same for the z/OS world as well.  I've had this happen to me a few times and it took a tedious study of the database values to find the issue.