OnDemand User Group
Support Forums => MP Server => Topic started by: jsquizz on February 02, 2019, 10:17:03 AM
-
I am trying to do an export of my application groups and dependent objects from my QA server and I am getting an error.
60 AG/350-ish Apps-
arsxml export -u admin -p ondemand -h archive -e c -r adpl -i exportAGs.xml -o exportedQAAgs.xml -v
Attempting login for userid 'admin' on server 'qaENV' ...
Searching applicationGroups for application .
Querying applicationGroup, AG00
Query of applicationGroup, AG000 was successful.
.................Runs for a few seconds
Query of applicationGroup, AG was successful.
Querying applicationGroup, AG1
Unable to allocate enough memory. File=arsapplg.C, Line=2360
I tried running this from my dev server to my QA server. Also directly on my QA server with the same result. ARSSOCKD does not crash, and nothing in the system log.
It's version 8.5.0.6. Has anyone seen this? Should i throttle it, maybe do batches of 10 or so?
-
I just checked the APARs for Content Manager OnDemand 8.5 & 9.0, and there's no mention of this bug being fixed.
Maybe try exporting the config from another machine, across the network, at a higher level of CMOD - v9 or v9.5.
-JD.
-
I'll try that, thank you!
No Bueno (Running on 9.5 Linux to 8.5 AIX) - ARS2084E The client and server are incompatible. Reinstallation of the product is required.
2.2.9.5.0.12) Release (9.5.0.12)
PH03836 - CMOD Server crashes when deleting Applications with the Windows Administrator or Batch Admin
Maybe this is related? shrug.
-
Yeah, most CMOD utilities are x-1 support, so you'd want to spin up a machine with Content Manager OnDemand v9.0.0.9.
-JD.
-
Okay cool. I will try that. I figured it would work because I am able to arsdoc get directly from my 9.5 Instance to the 8.5 Instance.
-
I think there is an incompatibility between ARSXML V8.5 and ARSXML 9.0 and above.
I can't remember specifics, but I believe there was a design change.
Ed
-
I may be way off base here so if this doesn't make sense, then it probably doesn't.
Anyway...
Out in /usr/lpp/ars/V8R5M0/bin/xml/samples/ is exportgroups.ebcdic.xml and exportgroups.xml.
Looking at some old 8.4 JCL of mine my job looks like this (I know, I know, this isn't z/OS and JCL doesn't apply and this is 8.4 but...)
arsxml $PRM1 -u edward $PRM2 $PRM3 -o /tmp/xmlo'
where the variables get resolved thusly:
PRM1=export
PRM2=-h ARCHIVE -p oomowmow -v
PRM3=-i /usr/lpp/ars/V8R4M0/bin/xml/samples/exportgroups.ebcdic.xml
CLASSPATH=/usr/lpp/ars/V8R4M0/bin/xml/ODAdmin.jar:
/usr/lpp/java/J1.4_64/lib/core.jar
LIBPATH=/usr/lpp/ars/V8R4M0/bin/xml:$LIBPATH
PATH=/usr/lpp/java/J1.4_64/bin:/usr/lpp/ars/V8R4M0/bin:$PATH
/*
Dunno if that helps at all but thought I'd chime in. (shrug)
Ed
-
when i don't use the -r flag to include dependant app groups, it works..strange.
-
when i don't use the -r flag to include dependant app groups, it works..strange.
Interesting.
Ed
-
when i don't use the -r flag to include dependant app groups, it works..strange.
Interesting.
Ed
I have seen this before, but i forget what I did to fix it, LOL.
I shall play and report back!
-
I tried this on the my 9.5.0.12 z/OS system including the "-r adpl" parms, worked fine.
Ed
-
Looks like when I use the admin client to do a direct export, these fail also.
Also, trying this in 9.0 -- > 8.5 is not working either.
ARS2084E The client and server are incompatible. Reinstallation of the product is required.
-
Bumppity :)
So, I am still getting this error when I try to run ARSXML, the only thing I have not tried is throttling, and doing it in bundles of 10 or so, which shouldn't be hard because we only have about 60 AG's.
Another question- Other than manually updating the ARSXML after exporting it..Is there a way that I can export the App group definitions with No Storage set, much like I would if I was using the admin client? I only ask because in our new system we are using different storage and I think it would be easier to do it manually, though I could be wrong.
I don't think that using a 9.0 system as a go-between is an option unfortunately...As much as I would like to.
I guess ARSXML is my only option here, to export everything, and manually change the AG storage settings and then re-import them to CMOD. What's everyones thoughts? Just looking for feedback or what everyone has done, especially going from 8.5 to 10.1 (Without manually moving the database/cache/storage..We are doing a complete 100% reload)
-
When we migrated from an 8.5 system (windows) to a 9.5 system(z/OS) I used ARSXML with a lot of manual manipulation of the xml export, including storage, to get the items to be defined correctly. Seemed no way around it at the time.
-
When we migrated from an 8.5 system (windows) to a 9.5 system(z/OS) I used ARSXML with a lot of manual manipulation of the xml export, including storage, to get the items to be defined correctly. Seemed no way around it at the time.
I think that's my only option at this point sadly. Instead of trying to figure out why arsxml keeps crashing, on an old version, on servers that are going away. Thanks for the feedback
-
When we migrated from an 8.5 system (windows) to a 9.5 system(z/OS) I used ARSXML with a lot of manual manipulation of the xml export, including storage, to get the items to be defined correctly. Seemed no way around it at the time.
I think that's my only option at this point sadly. Instead of trying to figure out why arsxml keeps crashing, on an old version, on servers that are going away. Thanks for the feedback
I have found that sometimes, old servers have not nice configuration of AG/APP/Folders for some reasons... that the admin was tolerating at one time, and then no more, but the db was "corrupted" slightly that you don't see the problem in the day to day production, but only when you do export such quirks appears.
And doing what you need to do is a wonderful way to clean up things.
BUT between XML from V8.5 and V9+... you have a lot work manual work to do, or script to do in order to convert from one format to another.
And don't worry, you could upgrade from CMOD V8 -> V10 in one shot without problems. The upgrade process is quite perfect in that area.
The only moment you might need to go to V9 is only if you use ODF/RDF.
Regards,
Alessandro
-
When we migrated from an 8.5 system (windows) to a 9.5 system(z/OS) I used ARSXML with a lot of manual manipulation of the xml export, including storage, to get the items to be defined correctly. Seemed no way around it at the time.
I think that's my only option at this point sadly. Instead of trying to figure out why arsxml keeps crashing, on an old version, on servers that are going away. Thanks for the feedback
I have found that sometimes, old servers have not nice configuration of AG/APP/Folders for some reasons... that the admin was tolerating at one time, and then no more, but the db was "corrupted" slightly that you don't see the problem in the day to day production, but only when you do export such quirks appears.
And doing what you need to do is a wonderful way to clean up things.
BUT between XML from V8.5 and V9+... you have a lot work manual work to do, or script to do in order to convert from one format to another.
And don't worry, you could upgrade from CMOD V8 -> V10 in one shot without problems. The upgrade process is quite perfect in that area.
The only moment you might need to go to V9 is only if you use ODF/RDF.
Regards,
Alessandro
I tried this yesterday. I exported one of the heaviest used AG's from our system, and tried exporting it directly to 10.1 with a newly created storage set. It looks like everything worked, except there is the one field depricated and ARSXML doesnt like it, it's logDBqueries or something. So I'm going to have to tinker with that a bit. I was going to change that logging anyway.