Adding your PDF indexing parameters from your Application Definition, and showing the relative size of the files will help us figure it out.  :)

-JD.

We are trying to enable ODWEK trace on one of our JVM's running a custom ODWEK app. Unfortunately, we are out of support - and the only documentation that we've been given is that we need to recompile our code, adding information about the trace.. which does not seem possible.

Anyone in a similar boat?

I am finding several thousand files on the OnDemand v.10.5 RHEL server that have the files names that end in
.PDF.out0
.PDF.out1
.PDF.out2
.PDF.out3

We are using the PDF Indexer to index and load new PDF files. It seems that all new files have been loading successfully. Are these temp files?   What process added created these files?  Can they be deleted?

Any clues would be helpful.

Thanks,

Basic troubleshooting steps:

 - Make sure the command you're running specifies the full path to the stash file. (/home/archive/ARCHIVE.stash rather than ARCHIVE.stash)
 - Double-check your user id and permissions - does the OS allow you to access the file?

Easiest way forward would be to back up the original stash file and create a new one in its place -- if you don't know the current password, you can change it through the admin client to a new password and use that password to create the new stash file.

Of course, if you create a new one, make sure the OS ownership and permissions are restrictive enough to be secure.

Good luck, and please report back with a resolution.

Thanks.

-JD.

I installed CMOD 10.5.0.0 on a new Windows server and configured it. I was able to successfully use arsstash.exe to stash the ID and password in a stash file.

I then upgraded the server to 10.5.0.8 and now the arsstash command errors out including when trying to change the configuration using the OnDemand Configurator.

The error displayed is:
ARS1602E The stash file >ARCHIVE.stash< is invalid.

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.

This helps immensely, I cannot thank you enough.
I have fixed my FIRST OnDemand problem.
The problem was that this, FIELD3=4,-12,35,(TRIGGER=3,BASE=TRIGGER) instructed to go 4 lines down after finding the '.' (which is an amount, not part of the address). But it only needed to go 2 lines down. This tool will help a lot in the future.

Hi Lori -

As of this date, nothing has been announced.

I get occasionally asked when is the next release is coming out.

I can truthfully say I have no idea. The Chief Architect does not confide in me.  :-)

However, I can say that in the past support continues for at least 2 years for the n-1 level of CMOD after the new "n" level is announced.

I anticipate even if a new release is announced today you'll have all of 2026 to implement it.

I also know that new function is being promulgated via fixpacks, so it pays to stay fairly current.

A good ref:

https://www.ibm.com/support/pages/how-do-ptf-numbers-relate-content-manager-ondemand-product-version-numbers-and-maintenance-fix-packs

Ed

I think we are finding that on Sunday only the QUSROND Server job is not yet started before the MONOUTQ job, so the MONOUTQ job is trying to process the spool file from the outq before the server job is ready.  Would this cause the spool file to be sent to the Error outq in Error status?