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;

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.