I currently have my arsload libraries defined for the CMOD arsload daemon as /app/arsacif/acif1 /app/arsacif/acif2 and /app/arsacif/acif3.
I want to define another file system /app/arsacif/acif4 that will be strictly for input coming to be indexed with the Generic Indexer with the load triggered by a scheduled script. The expected payload could be (more or less) 20k of PDF files (the source doesn't want to put them in one large file anymore because it becomes too large for them manipulate).
Is that a good or bad idea?
I'm trying to brainstorm ideas to keep this payload in CMOD. I've already told the client that we won't accept individual pdf files to load one at a time. Been there, done that and loading took too long.

Output from my DISPLAY GROUP command:

*** BEGIN DISPLAY OF GROUP(........) CATALOG LEVEL(V13R1M505)
                  CURRENT FUNCTION LEVEL(V13R1M506)           
                  HIGHEST ACTIVATED FUNCTION LEVEL(V13R1M506)
                  HIGHEST POSSIBLE FUNCTION LEVEL(V13R1M506) 
                  PROTOCOL LEVEL(2)                           
                  GROUP ATTACH NAME(....)                     

This is an OAM APAR that affects Db2 Allocations

OA68939: UPDATE OAM'S OBJECT SUPPORT SAMPLE JOBS TO WORK WITH NEW VERSIONS OF DB2

https://www.ibm.com/support/pages/apar/OA68939

Error description
As of APPLCOMPAT V12R1M504, Db2 has deprecated support for the
creation of Segmented (non-UTS) tablespaces. This has caused
OAM Db2 sample jobs to implicitly create PBG tablespaces
instead of segmented which is desired at V12R1M504 and higher.

Within our CBRILOB sample, the LOB tablespace is being created
as PBG, however the auxiliary table space is still defined as
segmented which causes Db2 to return with SQLCODE-769.

CBRILOB requires an update to remain compatible with PBG.
Local fix
If APPLCOMPAT is V12R1M504 or higher, then Add PART clause to
the CREATE AUXILIARY TABLE. This will cause the auxiliary table
to become compatible with the LOB table space which is being
created as PBG at APPLCOMPAT V12R1M504 or higher.

Example:

 CREATE AUXILIARY TABLE osg_hlq.OSM_LOB_AUX_TBL
        IN         osg_hlq.OSMLATS
        STORES     osg_hlq.OSM_LOB_BASE_TBL
        COLUMN     OTOBJ
        PART       1;

I find ODUG to be a helpful resource. There is information here that you can't find elsewhere/AI. I don't post, but I come here looking for information and would certainly like to see it continue. Thanks.

I am in a similar position as others in this thread. While I do not contribute much myself, I have been able to solve many issues or at least get some relevant details about some questions/concerns thanks to this forum. AI searches on OnDemand topics have been really horrible for me as well.

I have really appreciated this forum and would love to see it continue.

I would like to see this website continue. Although, I do not post much on the site, I have found a lot of answers to issues I have faced over the years on the site.

John Kyle

The end result determined that when the number of documents in a batch was increased (up to 12000) the RESTYPE=ALL created very large resource files. Per IBM when resource files approach 500MB, there's increased search overhead to search a large resource file by arspdump to rebuild the documents when retrieved. We changed RESTYPE=NONE and haven't seen this issue since but that increases our storage footprint for the documents.

I did get a few "Hey, I can't reach ODUG" eMails and texts over the past two weeks...  :D

-JD.

It's decent reference source when one can't get direct answers from IBM or when IBM says sorry that's a Lab Services issue/problem/function. Like last week when I needed to interrogate a CMOD appgroup for documents greater than 5MB for a project. I eventually figured out how to do it.

I thought I was losing my mind last week when I went to reference odug for something CMOD and couldn't get it.  I'm glad you're back.