It's been too long since I updated everyone.

The good news is that CMOD is doing very well in the marketplace.  I hope I'm allowed to say that  :-) 

The even better news is because of that the Level 2 team has been expanding.

The z/OS Level 2 team remains the same:

- Larry Fitchett
- Brian Lauther
- Lamies Nesheiwat
- Ed Arnold

The IBM i Level 2 team is:

- Greg Hidalgo
- Leo Gemma
- Jason Anderson

And over on LUW we have a deep team:

- Ted Tan
- Tejaswini (we call her "Tej") Jamakhandi
- Krishna Nagaraja
- Akshay Sai
- Jamie Long
- Tim Wood
- Patricia Virtucio
- Nanping Li
- John Link
- Tam Tran
- Sundar Shunmugam

I'm putting my functional requirements document together and step one will be send the pdf's first with the caveat that if they don't we'll have more administrative overhead. There's a custom process that uses the CMOD user exit for additional processing.
The vendor is going to be responsible for quality control.
As far as the daemon starting the load, it won't unless you know something other than what is stated in the IBM documentation. The files the daemon will automatically load are .ARD and .PDF. From the manual (online) "The ARSLOAD program will process any input file that has a file type of ARD or PDF."
That's why the new location will be out of the ARSLOAD daemon "view" and under the control of a script.

RESTYPE=NONE means you aren't getting any of the benefits of CMOD's 'deduplication' of PDF resources.  What sort of documents are you storing?  Are these PDF statements, or do they include something like cheque images, where each PDF file is large because it contains mostly-unique images?  If that isn't your use case, then it may still make sense to store SOME resources, since you *are* using the PDF indexer, and could benefit from storing fonts as resources.

-JD.

If you can convince them to send the index files *after* all the PDFs have been uploaded, that would be best, and you can leave an arsload daemon running that will ingest the files when that index file arrives.

Otherwise, having an entire filesystem set aside is a good idea -- having more than 10,000 files in a single directory usually causes headaches with performance when you are using the 'ls' command or trying to use wildcards.

Also, I'll provide the standard advice -- invest some time in building a utility that will read the generic index file, and ensure that each of the files it describes actually exist in the directory before starting the load. 

-JD.

You already plan to load the PDFs from the new file system using a special script triggered on schedule.

What if that script has a step where 100 of ".IND" files are merged into one large ".IND" file?

This way, the sender would send the 20K single PDFs into the landing zone, just as they prefer, and you will have a script to group them into larger .IND files for efficient CMOD storage and move the merged .IND files into a directory CMOD monitors. Your PDF landing zone will be used by your script to prepare the merge.IND files for the monitored directory.   

This only affects customers running ODF and upgrading past Java 8.

So -

IF you run ODF
AND IF you are upgrading your default Java to anything newer than Java 8

THEN

- ODF ships a sample version of ODFProcessDist.java and a ODFProcessDist.class file compiled at java version 8.

- Java made a change after version 8 of mail functions they include with java.

Therefore, if customers want to use a higher level of Java they must do the following:

1) upgrade to CMOD 10.5.0.9 or higher

2) compile the sample version of  ODFProcessDist.java at the level of java they are running

3) copy the class file generated into their ODF jars directory.

Ed

Had a report concerning moving from 2.5 to 3.1 doing LDAP configuration work, received the following:

ICH408I USER(ARSSOCKD) GROUP(U#STT  ) NAME(CONT MGR ON DEMAND )
 CSF1SKE CL(CSFSERV )                     
 WARNING: INSUFFICIENT AUTHORITY - TEMPORARY ACCESS ALLOWED   
 ACCESS INTENT(READ  ) ACCESS ALLOWED(NONE  ) 

If you search here in the ODUG on CSFSERV that message has observed many times.

Contact ICSF or RACF support if this is an issue for your shop.

Ed

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;