Author Topic: Move data loaded in an AP to another different AP  (Read 2669 times)

AlejandroGonzalez

  • Guest
Move data loaded in an AP to another different AP
« on: March 13, 2019, 10:01:26 AM »
Hi all,

I need your help please. Currently I made some massive uploads in Ondemand V9.5 and it turns out that there are some files that load them in the wrong "AP". Will there be any way to move those documents from one application to another without having to download them? ...

It has occurred to me to obtain the list of the erroneous input files and to throw some update in DB2 or something like that ... but I do not know if it is correct.

I hope you can support me with your ideas. Thank you.

Alex Gonzalez.
Cmod Admin
México.

jsquizz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 572
    • View Profile
Re: Move data loaded in an AP to another different AP
« Reply #1 on: March 13, 2019, 10:21:54 AM »
Look into arsdoc get, using the -X flag for load ID. Once you get the file retrieved, load it via arsload into the correct application group/app
#CMOD #DB2 #AFP2PDF #TSM #AIX #RHEL #AWS #AZURE #GCP #EVERYTHING

AlejandroGonzalez

  • Guest
Re: Move data loaded in an AP to another different AP
« Reply #2 on: March 13, 2019, 10:27:45 AM »
Hi jsquizz,

Excellent, I will do a test and I keep you informed with the exact command to do it.

Thank you.  8)

AlejandroGonzalez

  • Guest
Re: Move data loaded in an AP to another different AP
« Reply #3 on: March 21, 2019, 09:23:31 PM »
Look into arsdoc get, using the -X flag for load ID. Once you get the file retrieved, load it via arsload into the correct application group/app


Hi all,

I have done what jsquizz indicated and the sentence that retrieves my files has been left like this:

/opt/IBM/ondemand/V9.5/bin/arsdoc get -h XXXX -u admin -p XXXXX -X 5510-53-0-21839FAA-0-0-5511 -G AM_TDC -o /opt/IBM/ondemand/V9.5/recupera/prueba.afp -v


It does the recovery process correctly:

2019-03-21 17:27:24.400405: ARS6095I Document successfully retrieved and stored in file '/opt/IBM/ondemand/V9.5/recupera/prueba.179'

2019-03-21 17:27:24.403904: ARS6026I arsdoc completed.


But they are files that I can not read, I do not know in what format or code page they are downloaded. I loaded afp's.
Will anyone know how I can read them? or do I have to put a specific extension? or how can I load them into the application group I want as well as download them?

I tried arsdoc add, but it does not work, I tried to load it with arsload and it sent me an error in the indexing ...

Someone to suggest something to me? ...


jsquizz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 572
    • View Profile
Re: Move data loaded in an AP to another different AP
« Reply #4 on: March 22, 2019, 05:56:55 AM »
Are you trying to load them, or ready them? If trying to load them --- try using arsload, with flag -X G, to force CMOD to use the generic indexer

Heres how I usually do it-

arsload -nvf -I instance -u admin -p *** -a app -g appgroup -X G filename.noextension
#CMOD #DB2 #AFP2PDF #TSM #AIX #RHEL #AWS #AZURE #GCP #EVERYTHING

AlejandroGonzalez

  • Guest
Re: Move data loaded in an AP to another different AP
« Reply #5 on: March 27, 2019, 11:40:26 AM »
Hi all,

I already solved the situation. The download syntax was wrong. I leave the correct one, with this, the afp will be downloaded as .out, the .ind and the .res ... already with those files you will be able to go back to realize the load as it says jsquizz ...


RECOVERY:
/opt/IBM/ondemand/V9.5/bin/arsdoc get -h "instance" -u admin -p "xxxx" -X "Load ID" -G "Application" -acg -o "path and name of output file" -N -v

ARSLOAD:
/opt/IBM/ondemand/V9.5/bin/arsload -nfv -u admin -p "xxxxx"-I "instance" -a "application" -g "application Group" -X G "path and name of output file"


ELIMINATE FROM THE INCORRECT APP:
/opt/IBM/ondemand/V9.5/bin/arsadmin unload -u admin -p "XXXX" -h "instance" -g "application" -L 5503-44-0-355FAA-0-0-5504


Dear jsquizz, thanks for the support. It has helped me a lot if some day I see you, I'll invite you a cold beer. 8)