The PDF indexer is multi-threaded. Each thread produces an output file.  The load process combines them into the objects that are actually archived.  If the load is successful all of those intermediate files should be deleted.  Is it possible that you have files that are failing and leaving these intermediate files on the system?
As an example, a small PDF file (184k), when running index only, produced these files:
MH_MartForms_176pg.pdf.ind   
MH_MartForms_176pg.pdf.out.003
MH_MartForms_176pg.pdf.out.004

In a quick test, the spooled files were sent in a HLD status.  The monitor joblog contained OND2798 ARS1106E Connection cannot be established for the >QUSROND< server.
I suggest that the monitor be started with the parameter STRSVR(*YES).  That should fix the issue going forward.  If the server is already active, then the only overhead is a couple milliseconds verifying that is it active.

They are trying to explain how to look at sample data in the Administrator Client.  Open the Administrator Client.  From the list of Applications, right click and select update on the application in question.  Go to the Indexer Information tab, click on Modify with Sample Data.  You can either download a spooled file at that point, or use sample data previously downloaded (see previous advice on manually downloading sample spooled data).  On the tool bar there is an icon with red, blue, and green horizontal lines. Click that to toggle to Display mode.  The triggers on the page are boxed in red, the fields boxed in blue.  You can then scroll page by page to see where the problem is.

Also, if you click on the icon to the right of the Display/Add mode icon, that will pop up a dialog where you can generate a listing of Field Values found in the sample data.  (Click Field Values, click All Pages, click the Create button, then the View button).  Look thru the file for missing field values.

I hope this helps,

What messages are in the monitor joblog?  You might try starting the monitor with LOG(*YES) which will write more information into the joblog.

If the output queue monitor moves a spooled file to the error output queue in ready status, that means the application group and / or application definition were not found.
If the spooled file is moved to the error output queue in held status, you should have a system log message 88 containing the error, and probably some joblogs.

These are the type of questions that should go to support.  I suggest you work with your management to get back into a supported status so you can get the help you need in a timely fashion.

My apologies for the typo.
You use the Print Text (PRTTXTOND) command to determine how the spooled file appears to the 400 indexer. 
If you use the graphical indexer in the OnDemand Administrator client to view a spooled file and create / modify indexer parameters, Print Text is run in the background to create the sample data file which is then automatically downloaded to the PC.  Retrieving sample data from the Administrator client requires having IBM i Access Client Solutions and the accompanying Windows Application Package installed.  If you don't have those installed or have trouble with them, you can use the Print Text command with the Stream file (STMF) parameter to send the output to a stream file on your IBM i system.  That steam file can then be downloaded to the PC and used as input to the graphical indexer.

The quarterly OnDemand Newsletter has lots of great information about OnDemand on all platforms.  You can find all previous newsletters at:
https://www.ibm.com/support/pages/node/628001

The 3rd quarter 2016 newsletter, on page 5, has a tip entitled 'Creating sample data for a complete spooled file' which contains a good explanation of using the Print Text command and manually downloading the output to the PC.

If you would like to receive the newsletters as they come out, send me a note. darrell.bryant@unicomsi.com

Looking only at the relevant indexing information:

TRIGGER1=*,1,X'F1',(TYPE=GROUP)                          /* 1      */
TRIGGER2=*,*,X'61F2F0',(TYPE=GROUP,RECORDRANGE=(1,4))    /* /20    */
TRIGGER3=*,23,X'4B',(TYPE=GROUP,RECORDRANGE=(2,6))       /* .      */
FIELD2=0,-4,9,(TRIGGER=2,BASE=TRIGGER)
FIELD3=4,-12,35,(TRIGGER=3,BASE=TRIGGER)
INDEX2=X'A8858199',FIELD2,(TYPE=GROUP,BREAK=YES)         /* year   */
INDEX3=X'8595A389A3A8',FIELD3,(TYPE=GROUP,BREAK=YES)     /* entity */

Trigger 1 is carriage control (hex F1) for start of new page. Once that is found by the indexer the other triggers will be searched for.  (Hex F1 is at the top of every page, it is not the ideal trigger 1, but that is a topic for another day)

Trigger 2 is the string '/20' (w/o quotes).  It is searched for in any row and column (that is the meaning of *,*) in a range of records from 1 to 4 rows below trigger 1.  Once it is found searching stops (i.e. if it exists more than once in those rows, only the first one is used)

Trigger 2 is the period character.  It is searched for in column 23 in a range of records from 2 to 6 rows below trigger 1.  Once it is found searching stops (i.e. if it exists more than once in those rows, only the first one is used)

Field 2 is located using trigger 2.  It is located relative to trigger 2 (that is the meaning of BASE=TRIGGER).  It is located on the same row as trigger 2, and 4 columns before the start of trigger 2.  (That is the 0,-4 on the parameter). The length of the field is 9 characters.

Field 3 is located using trigger 3.  It is located relative to trigger 3.  It is located 4 rows below trigger 3, and 12 columns before the start of trigger 3.  (That is the 4,-12 on the parameter). The length of the field is 35 characters.

Index 2 is composed of the contents of field 2.  The field name is year.  The break equal YES means that if this value changes a new document is started.

Index 3 is composed of the contents of field 3.  The field name is entity.  The break equal YES means that if this value changes a new document is started.

If the report layout was changed and the location of the field(s) moved on the page, the indexer parameter must be updated to capture the data at its new location.

I hope this quick overview helps.

You specifically want to read the section on the 400 Indexer, which is used on IBM i.
https://www.ibm.com/docs/en/cmofi/7.5.0?topic=ondemand-400-indexer

Archiving spooled files is done using an output queue monitor.  This documentation should be helpful as a starting point.
https://www.ibm.com/docs/en/cmofi/7.5.0?topic=ondemand-loading-spooled-file-data

Which platform are you using?
Archived Storage Manager (ASM) is the native storage manager used by Content Manager OnDemand for i.
ASM supports NFS mounted drives for long term archive storage.

Hello Olivier,
The ODi development team has documented the setup for archiving from IBM i to other platforms.
See support item: https://www.ibm.com/support/pages/node/321611
You might consider signing up for the OnDemand Newsletter, the 2Q2023 issue referenced an update to that support item.
To sign up for the newsletter, drop me an email, darrell.bryant@unicomsi.com

IBM's education partner for Content Manager OnDemand is enChoice.  Information on their education offerings can be found at:
https://www.enchoice.com/Learn/IBMCMODEducation

Quote from: New-Z/osCMODuser on June 12, 2023, 08:23:17 PM
It is  messaging audit rule to store any data that to be encoded  . .  If there is No other option We should opt for loading original xml data  itself ,

Content Manager OnDemand supports encryption at rest.
See https://www.ibm.com/support/pages/ibm-content-manager-ondemand-native-encryption

The Content Manager OnDemand Best Practices Guide, found here:
https://www.ibm.com/support/pages/content-manager-ondemand-best-practices-guide
recommends a setting of 120000.
Absent any newer information, I would start with that recommendation.

Any change to ARS.CFG requires a restart of arssockd.

If you have a test environment, you might experiment with the ARS_USE_OLD_STYLE_CASE parameter in the ARS.CFG file.

Use the following if upper casing expands the number of characters, for example the German Ezett (�) expands to SS with the new style (ICU) upper casing
In the ARS.CFG:
# Use old style upper casing to prevent character expansion
#
ARS_USE_OLD_STYLE_CASE=1

When value of ARS_USE_OLD_STYLE_CASE is:

(0) - then we do all upper/lower casing in UTF-16 (no change)
(1) - then we do all upper/lower casing in OS level codepage we are running under (no change)
this was really added just to prevent the german sharp s (�) character not expand to multiple bytes (which it does in UTF-8)
(2) - we now upper/lower case in UTF-16 (however we specifically prevent � from being done).
We then convert this back to the native codepage (of the data) - then compare to the original string that was provided to us.
If we find any characters that are not found (e.g. ICU will change the char to be a substitution char),
we will put the original char back into the upper/lower case string. If for any reason this fails we will
default as if the ARS_USE_OLD_STYLE_CASE=1 for that string.